This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If you have a classpath entry for a source root which has a matching source entry (SFBQ), it seems that classpath scanning will (as of 4.1?) entirely ignore the actual content of the binary classpath entry and only look at the source entry. This was done for a good reason: to avoid double parsing. But the problem is that this policy can make it impossible to *add* source associations in some cases without breaking existing functionality. There are two cases of interest: 1. A bootstrap classpath (e.g. Java platform) includes a bunch of binary JARs for which no sources are available, plus the usual Java platform classes. If you add a src.zip association, you lose code completion for the other classes. This dilemma is illustrated at the end of http://wiki.java.net/bin/view/Netbeans/FaqJdk11 I am not sure whether it is intentional that code completion against a Sun JDK refuses access to non-Java-platform classes in rt.jar, or whether that is related to the scope of $jdkhome/src.zip vs. being handled as a special case. 2. A classpath entry includes only a limited number of classes but the corresponding source root includes many other sources which are not actually available to compile against. If you add the source association, you expose unwanted classes in code completion (that will in fact display errors in the error stripe if you try to use them). See issue #59792 for motivation. This case could perhaps also be solved using issue #49371 (package restrictions on classpath entries), though that would be more cumbersome to implement I think. 3. I imagine various problems arise in mildly misconfigured user libraries as a result of the current behavior, but I don't have specific examples handy. So this request is for an adjustment to classpath scanning behavior: when sources are available, scan only those source files (packages?) which match actual class files (packages?) present in the binary classpath entry; and produce sourceless Java model entries for classes (packages?) present only in binary form but not in source form. I think the performance impact would be small - you still would not need to parse *.class files for which sources are available, though you would need to enumerate the names of *.class files in the classpath entry.
Do you have any opinion on this? There may be an additional issue I did not think of when reporting this - when project A depends on project B, and you have both open and rebuild B, you do not want to rescan b.jar (this was a bug in javacore long ago that was fixed and ought not be rebroken). Perhaps it would be acceptable to quickly examine b.jar for its list of classes - assuming that b/src/ contains the same classes, this would not be nearly as expensive as a full scan. But it would still expose javacore to the risk of encountering the JRE crash bug involving deleting or modifying an open JAR (if another clean build takes place while b.jar is being checked).
Created attachment 28105 [details] Sample project
Try the sample project. C1, when built by Ant, can refer to A1 and B1, but not A2. But 1. Uncommenting "new a2.A2();" leaves a green box for the background compiler, even though the Ant build will fail. 2. No code completion is available for B1, Fix Imports does not work on it, etc.
Javacore module was replaced by Retouche infrastructure. This bug is not valid in trunk any more.
Hold on, did you actually evaluate this against Retouche infrastructure? The problem may just as well apply to it, assuming you did not change the fundamental logic of classpath scanning.
Jesse is right, the issue is still valid. Reassigning to retouche.
Sources are taken only from projects, libraries are taken as binaries. If you want to sources to be used, create a project from the library. Checking in nbproject/project.xml; /cvs/java/source/nbproject/project.xml,v <-- project.xml new revision: 1.25; previous revision: 1.24 done Checking in src/org/netbeans/api/java/source/ClasspathInfo.java; /cvs/java/source/src/org/netbeans/api/java/source/ClasspathInfo.java,v <-- ClasspathInfo.java new revision: 1.10; previous revision: 1.9 done Checking in src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java; /cvs/java/source/src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java,v <-- GlobalSourcePath.java new revision: 1.11; previous revision: 1.10 done
"Sources are taken only from projects, libraries are taken as binaries." - I guess by this you mean that libraries with associated sources will still display pop-up Javadoc correctly (and allow Go to Source etc.), but only classes actually present in the JAR are considered. Is this correct?
Yes.