Community
Participate
Working Groups
I'm unsure whether this is a Core or UI problem. It's reproducable with 2.1RC1. Create a project and add the two classes shwon below. The code will be compiled without errors. However, if you open an editor on A, there's an error that C can't be resolved or isn't a valid type. There's no error shown in the task view though. It doesn't matter whether A and B are public classes or not. However, if you make C also public (which of course is an error) the task view also shows the "C cannot resolved" error. // A.java class A { C c; } // B.java class B { } class C { } This is a minimal example but the problem gets really annoying for larger projects like Coco/R which has a lot of small helper classes combined in a single compilation unit. Even if you switch of "Analyse annotations while typing" you cannot select "C" and press "F3" to goto its definition. There's an error shown in the workbench's status line.
Secondary types in compilation units are known to cause some grief. As soon as A will refer to B, C will be found from there on. Note that other tools could also miss C, e.g. use a command line compiler, and tell it to compile A.java with B.java available only on the classpath... C will not be found as it isn't matching a corresponding file name, or hasn't been discovered while resolving a reference to B prior to this point. Using secondary types outside a compilation unit is really not a good thing to do, and in order to handle this better we would have to eagerly open and parse all available types to see if a secondary type is a good match. Performance wise this would be deadly.
Philippe is right that this is bad style. However, is legal bad style and it is very irritating that errors are generated. With Coco/R, the right error bar is red. Perhaps the error should be only a warning or should otherwise indicate that it might be a false error, perhaps even sugesting to add a reference to the compilation unit's primary class.
Bad style doesn't mean we should not tolerate it anyway (life would be so boring if we only had to compile correct code<g>). What I wanted to point out is that depending on involved tools, there is a chance to recreate the same 'false' problem, it is only a matter of how hard you try to break it. Using the command line compiler, the same issue can happen (as I said in earlier comment). Or consider our incremental builder, and previously discard the C.class from the output folder. Basically, it relies on the fact someone told it to produce C.class at some earlier stage. The source model is not that different with respect to this issue, and its setup makes it quite easily fall into this trap.
Deferring
Dup
*** This bug has been marked as a duplicate of 32505 ***
Verified for 3.2 using M20060629-1905.
