Community
Participate
Working Groups
HEAD IJavaProject#isOnClasspath(IJavaElement) returns false for a type from a referenced JAR (referenced from a CPE_LIBRARY JAR that is on the raw classpath). Looks like the last loop in the implementation misses the CPE_LIBRARY case. It only resolves CPE_CONTAINER and CPE_VARIABLE. Found this while looking at the breadcrumb of a type from a referenced JAR.
Markus, Looks like we do not take referenced JAR in to consideration at all, for all three cases - CPE_VARIABLE, CPE_CONTAINER and CPE_LIBRARY. What we really do for the first two cases is that we only resolve the variable/container and don't look resolve for referenced jars at all. The switch/case doesn't include CPE_LIBRARY because they would have already been considered in the the previous block, where we look in to raw classpath. So, in that way, the code is consistent. Let me know if you still think this behavior is a bug.
Yes, it's still a bug (it's not new though, it's wrong since the support for referenced JARs has been added). The contract just says "referenced from a classpath entry". It's not explicit, but this actually means "inside an entry from the resolved classpath". It cannot mean "inside an entry from the raw classpath", since otherwise, e.g. elements from rt.jar in the 'JRE System Library' container would also not be included. That's actually a case of CPE_CONTAINER. The new "referenced via Class-Path in MANIFEST.MF" is a new way how JARs can end up on the resolved classpath, so it should be supported by this method. I first thought we only need this for CPE_LIBRARY and CPE_VARIABLE. But then I've put a JAR with a Class-Path attribute into a user library and saw that the referenced JAR also ende up on the resolved classpath. So, you also need to support this for JARs from CPE_CONTAINERs.
Created attachment 160747 [details] Proposed fix Proposed patch with regressions tests - ClasspathTests#testBug304081, testBug304081a and testBug304081b I have modified the code to look for entries in the resolved classpath, instead of resolving raw classpath entries again. The resolved classpath entries will have all the referenced JAR entries. Satyam, can you review the patch, please?
The changes look good to me. However, here is an optional change that can be done. This patch is unnecessarily re-verifying for the projects that are on the raw class path. If that can avoided, it could be great.
(In reply to comment #4) > The changes look good to me. However, here is an optional change that can be > done. This patch is unnecessarily re-verifying for the projects that are on the > raw class path. If that can avoided, it could be great. When it comes to resolved classpath, we can not guarantee that the raw classpath entries will all appear before the resolved classpath entries. In particular, the referenced classpath entries are likely to appear before the library entries that is referencing them, in which case, which we do not want. Hence, keeping the code as is with the previous patch. Satyam agrees with this.
Released in HEAD for 3.6M6.
Verified for 3.6M6 using build I20100305-101
Verified.
