Bug 70220 - Mismatches between scope of sources and binaries not handled well
Mismatches between scope of sources and binaries not handled well
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Source
5.x
All All
: P3 (vote)
: 6.x
Assigned To: Tomas Zezula
issues@java
:
Depends on:
Blocks: 59792
  Show dependency treegraph
 
Reported: 2005-12-11 18:20 UTC by Jesse Glick
Modified: 2007-08-21 16:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Sample project (3.80 KB, application/octet-stream)
2005-12-30 19:19 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-12-11 18:20:34 UTC
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.
Comment 1 Jesse Glick 2005-12-19 16:46:24 UTC
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).
Comment 2 Jesse Glick 2005-12-30 19:19:55 UTC
Created attachment 28105 [details]
Sample project
Comment 3 Jesse Glick 2005-12-30 19:22:16 UTC
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.
Comment 4 Jan Becicka 2006-10-26 16:27:19 UTC
Javacore module was replaced by Retouche infrastructure. This bug is not valid
in trunk any more.
Comment 5 Jesse Glick 2006-10-26 17:38:43 UTC
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.
Comment 6 Tomas Zezula 2006-10-26 19:25:00 UTC
Jesse is right, the issue is still valid. Reassigning to retouche.
Comment 7 Tomas Zezula 2007-08-21 09:35:09 UTC
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
Comment 8 Jesse Glick 2007-08-21 16:33:31 UTC
"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?
Comment 9 Tomas Zezula 2007-08-21 16:34:43 UTC
Yes.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo