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
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
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
Created attachment 28105 [details]
Try the sample project. C1, when built by Ant, can refer to A1 and B1, but not
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
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
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
"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?