Community
Participate
Working Groups
We have a big java project with some source files containing a public class and one or several "default" top-level classes (inherited from the public one). - Java editor shows unresolved error where these default classes are used if the source file where these classes are defined is not also opened. (seems to be a known problem, see bug 87063,92486) - With the option "build automatically", Eclipse shows for some (not all) of these classes, the following error : <default class name> cannot be resolved to a type. I cannot reproduce this problem with the same project and the version 3.0.2 of Eclipse on a different PC.
Could you please provide a test case for investigation? What happens if you do a clean on your project?
(In reply to comment #1) > Could you please provide a test case for investigation? Unfortunately, I'm not authorized to give you the whole project and all connected jar files. I tried to create a new project with some classes reproducing the "structure" that failed in our project, but without success. The project compiles well. > What happens if you do a clean on your project? The compilation error stays. On other PCs, with Eclipse 3.0.2, the compilation errors appears after the "Clean". So, this problem is not only on the version 3.1. I managed to remove these compilation errors following the next steps : - Open the file which fail to compile - Do and undo a small change in it - Save the file. => The file is compiled and the errors disappear.
It seems to depend on the compilation order. A file using a default top-level class won't compile without errors if the source file where this default class is defined is not already compiled at that time. If I knew in which order the source files are compiled after a clean, I would be able, may be, to produce a test case.
I have the same issue with my java application project. I saw this with 3.1.0 and it still exists with 3.1.1. When I open the .java source file (from the same package) that contains the class that could not be resolved, then those same errors clear up.
I'm using Eclipse 3.1.1 on Linux and I experience the same strange behaviour with a rather big project (thousands of classes). The compiler shows in the "Problems" view "The import xxx.yyy.zzz cannot be resolved", I navigate to the error line, press Ctrl and click on the imported class and (surprise!) it exists, alive and kicking. It's a Java class within the same project, in sourcepath. In contrast with previous commenters' experience, even if I pretend to edit the "not found" file, Eclipse doesn't find it after saving. Other classes are not found as well, even if I can navigate to them (by Ctrl + click). There are also plenty of "XXX cannot be resolved to a type" messages. It's impossible to share with the Eclipse team these type of projects because they are privately-owned. Not even obfuscated, I guess. I also think this bug isn't reproduceable as it dependes on local factors (available memory, OS, who knows what else). You'll have to rely on your good hunch when investigating this problem. I believe you should look for memory problems in dependency checks: circular buffers? artificial limits like no more than N classes can be dealt with or no more than M passes over the dependencies ? flawed dependency checker/loader in the sense that it looses/overlooks entries? This is one huge argument of other IDEs supporters against Eclipse. Beware... ;)
Is anyone reading this? I'm talking about Eclipse not being useable in complex projects.
I was not able till now to reproduce this problem with the beta release 3.2M4. You may give it a try.
Could the fact that source folders (as there are more) are not listed in perfect alphabetical order in the Package Explorer view be a symptom of something wrong going on?
Source folders are listed in the order they are specified on the classpath. In the absence of steps, it will be hard to reproduce, and thus fix. Kent - could this have anything to do with MAX_AT_ONCE ?
Appears to be a duplicate of bug 126999. Can everyone confirm that the problems you're having are with secondary types in projects with over 1000 source files?
Yes, I agree that my project has over 1000 files. Looking at 126999, I agree that this bug is a duplicate... although, wasn't this one reported first? ;-)
I do not have a single .java file with two classes in it. I am experiencing the problem described above on Eclipse 3.1.2, too. Should I open another bug?
It doesn't have to have 2 classes in the source file. You just need 1 source file named X.java with a class named A. If all of your source files match the name of the declared type then please open another PR because your case is NOT the same as this one or bug 126999
The builder will now detect the secondary types compiled after the first group of types and recompile types dependent on them after the batch build is finished.
*** Bug 126999 has been marked as a duplicate of this bug. ***
Verified for 3.2 M6 using warm-up build I20060327-0010.
I still got this problem with Eclipse 3.2.0 I20060519-1206. The only difference with the old Eclipse version is that now less file are signaled faulty. The same workaround is still possible : Open the file which contains the unresolved class, do and undo a small change and save it.
Patrick, please reopen when you can provide a reproduceable testcase. Also clarify whether these problems appear after every clean build and does splitting the project up into several projects change the number of problems.
Hi Kent! Unfortunately, I cannot give you the whole project and I was not able to create a small testcase to reproduce this problem (see my previous comments). This problem occurs after every clean build. As I upgrade from a previous Eclipse version, I'd like to be sure that I'm using the fix you made. How could I check this ? It seems to me that I didn't get this problem for a while with previous 3.2Mx version and that I get it again with the version I have.
The fix that we thought solved your problem is in every 3.2.x build starting with M6. Can you try to split your project into 2-3 projects to see if it changes the behaviour at all? Or compute how many source files you have in your project.
Patrick, I've added bug 146324 to track your testcase (or at least the one I found investigating your case).
