Community
Participate
Working Groups
I am working on an adopter product building on eclipse 3.4. Here is the problem I'm running into; I have a plain Java project to which I added a server runtime to the classpath. Then in my source I reference a class that I know for sure is part of that server runtime, however, it shows as unresolvable. Some interesting observations: - I have to set the project's Java compliance level to 1.4 because the class I'm referencing has "enum" as a package name, so perhaps this has some effect on the error showing up. - The error shows up only in the editor. There are no error markers in package explorer or problems view. - The class is "unresolvable" yet the editor can tell me that it is deprecated. In open types dialog, the class is listed but when I try to open the type, an error says it cannot be found. - If I copy the jar to my project and add it to the classpath directly, then the class can be resolved. Please contact me directly for more information on how to reproduce this error.
Asked Andrew to send me steps to reproduce and build id.
Created attachment 101942 [details] Project to import After talking to Andrew, here are the minimal steps to reproduce 1. Build I20080523-0100 2. Start a new workspace on a 1.6 JRE 3. Import the attached project (there should be 2 errors in the Problems view) 4. Open Test.java in a Java editor 5. Open P's Properties, and change the Compiler compliance level to 1.4 (say Yes to rebuild) Observe: The Java editor still reports an error (p.enum cannot be resolved) but the Problems view reports a warning only
After restarting the workbench, the Java editor no longer reports the error (it reports the same warning as the Problems view)
Problem existed in 3.3.2
Created attachment 101999 [details] Proposed fix and regression tests
Since the problem is not a regression comparing to 3.3.2, since there is a workaround (see comment 3), and since we are at the RC3 stage, I will release this fix for 3.5 (and possibly backport it to 3.4.1)
Fix and test released for 3.5M1. Since the chances of running into this bug are low and there is a workaround, I prefer to not take any risk and not release it in the 3.4 maintenance stream, unless there is a strong push for it.
Verified for 3.5M1 using I20080805-1307
