Community
Participate
Working Groups
I20070306 + latest jdt.core 1. New workspace 2. Create project P1 with the following .classpath contents: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry combineaccessrules="false" kind="src" path="/P2"/> <classpathentry kind="output" path="bin"/> </classpath> 3. Create project P2 with the following .classpath: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="lib" path="D:/jdk1.5.0/jre/lib/rt.jar" sourcepath="D:/jdk1.5.0/src.zip"/> <classpathentry kind="output" path="bin"/> </classpath> 4. Exit/restart workbench 5. Open java.io.File 6. Select list(FileNameFilter) in Outline 7. References > Workspace => No matches are found 8. References > Project => 1 match is found in Classpath#getClasspath()
Debugging it shows that the search scope is being created with elements {JavaProject(P1), JavaProject(P2)} but the resulting scope doesn't contain rt.jar.
Problem is in JDT/UI land while creating the query. The JRE mask is set only if the package fragment root is the JRE Container (see isInsideJRE(IJavaElement) method in JavaSearchScopeFactory). But in the concerned test case, the rt.jar is added on the classpath as an external JAR file and so fails the test: if (entry.getEntryKind() == IClasspathEntry.CPE_CONTAINER) { => Move to JDT/UI
Shouldn't the library just be treated as application libary and hence be searched as well? Or in other words: why is JDT Core thinking that this library is the JRE?
(In reply to comment #3) > Shouldn't the library just be treated as application libary and hence be > searched as well? Or in other words: why is JDT Core thinking that this library > is the JRE? > You're right, the rt.jar file should be on the scope through the Libraries mask and so should not matter the JRE mask was not set => put back to JDT/Core land and continue to investigate...
OK, I got it now. The problem effectively comes from JDT/Core while building the JavaSearchScope (I guess it was already Jerome's intuition when he wrote the comment 1...). As the workspace is done with the two projects P1 and P2, the JavaSearchScope creation starts by adding the project P1 and loop on P2 due to the dependency. But as the library is not exported in P2, it is not added to the scope: if (referringEntry != null) { // Add only exported entries. // Source folder are implicitly exported. if (!entry.isExported() && entry.getEntryKind() != IClasspathEntry.CPE_SOURCE) continue; As the project P1 has been visited through the P1 dependency, it is not visited again when the we try to add the second project P2 to the scope. So, the library missed to the final built scope :-(
comment #5 should obviously read: ... As the project P2 has been visited through the P1 dependency, ...
Created attachment 86447 [details] Proposed patch
Released for 3.4M5 in HEAD stream.
Verified for 3.4M5 using build I20080204-0010.
