Community
Participate
Working Groups
Build Identifier: I20100727-1520 If a library precedes a source folder on the build path of a project, then the library should take precedence over the source folder whenever the JDT resolves a reference to a class in the project. This works correctly for Ctrl-click navigation in the Java editor, but not for the compiler. The compiler reports errors that indicate that it is trying to build against a class in the source folder even when a class of the same name exists in the library. I'm setting the severity "minor" because this is a very unusual use case. Reproducible: Always Steps to Reproduce: 1. Import the archive file (to be attached). 2. Open Client.java. Observe that Ctrl-clicking the call to doFoo takes you to the definition in the library, but a compile error is reported that is apparently based on the Foo class in the source folder (which does not contain the doFoo method).
Created attachment 194424 [details] Test case This should be imported with "Import" -> "Existing Projects into Workspace".
I don't know why would look for a type in another library entry when it's available in the current source entry that we are trying to compile. If we are talking about two different library folders, then definitely classpath order would be the deciding factor. But not in this case. I am afraid we can't do much here. Satyam, can you please check and let me know what you think?
JDT/Core is intentionally looking at the output folders before looking at the jars. This is good so that even if people don't really modify the class path ordering, the code in the source code will be resolved before the libraries. However, I agree that this is not correct. At the same time, I am afraid that this change could likely cause problems in some unknown scenarios. Matt, Do you really need this behavior?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
