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.

Bug 43593 - Scanning of explicitly named subfolders of JARs does not work
Summary: Scanning of explicitly named subfolders of JARs does not work
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Tomas Zezula
: 46468 (view as bug list)
Depends on: 42068
Blocks: 41448 44840 46455
  Show dependency tree
Reported: 2004-05-19 17:54 UTC by Jesse Glick
Modified: 2007-09-26 09:14 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-05-19 17:54:40 UTC
I modified my
to read:


Here I have full JDK sources in a ZIP file.

But it doesn't seem to work from the editor side.
When I reopened the IDE after making this change
(no GUI support currently), Tools -> CCDBM showed
an entry "/space/" which it scanned
for a long time and finally reported "Warning: no
parsable sources".

Alt-G, Alt-Shift-O, etc. are not working on
classes not in And


are empty (4 bytes each).

So something is mishandling the jar: URL and
assuming that the suffix after "!/" is empty when
it is not.

Haven't tried in a refactoring build - will assume
the code in question is rewritten there, so just
leave open until the refactoring merge and reevaluate.
Comment 1 David Konecny 2004-05-20 12:14:56 UTC
To my surprice this case is really not supported - relative path in
jar is simply ignored! It should not be that difficult to fix, but it
is in code obsoleted by MDR.

The workaround is to unzip sources and then in UI modify source path
of JDK.
Comment 2 Martin Roskanin 2004-05-20 12:37:04 UTC
Adding dependency on #42068.
Comment 3 Martin Roskanin 2004-06-07 13:07:46 UTC
I am closing it... meta_stavbicka was merged to maintrunk. The merge
fixes the problem, please verify.
Comment 4 Jesse Glick 2004-06-16 04:09:50 UTC
Doesn't seem to be working for me in 040615; I have the same platform
config XML file as before, and just uncommented the lines using
relative JAR paths. Don't see any evidence that it worked; at least, I
cannot open e.g. sun.misc.URLClassPath using Fast Open or Go To Source
(from URLClassLoader). Not familiar enough with the details of the MDR
storage now to know whether it is storing it, but I did not see any
scanning of these sources at startup time.
Comment 5 Jesse Glick 2004-06-16 04:17:54 UTC
But then I restart the IDE and now it works. Odd.
Comment 6 Jesse Glick 2004-06-16 19:33:43 UTC
But then sometimes after a restart it doesn't work. No clear pattern,
but not working reliably.
Comment 7 Martin Roskanin 2004-06-17 08:43:27 UTC
Since parserDBs were removed, I assume this could be MDR scanning
problem. Reassigning...
Comment 8 Jesse Glick 2004-06-17 17:01:40 UTC
Maybe. Could also be a library parsing problem, etc. I am really not sure.
Comment 9 Martin Matula 2004-07-18 22:17:23 UTC
Assigning to thurka.
Comment 10 Jesse Glick 2004-07-23 21:41:24 UTC
Still broken. For JDK 1.3.1 I use


In the scanning dialog (if I start the IDE with an empty cache) I see e.g.

Scanning: ...//src
Package: src.javax.swing
Comment 11 Jesse Glick 2004-07-23 21:46:47 UTC
The FileScanner class is clearly wrong. Its constructor has

public FileScanner(File _root, String sourceLevel, Codebase cb) {...}

which cannot work for JAR entries, and later it says

if (name.endsWith(".jar") || name.endsWith(".zip")) {

And JMManager is wrong:

URL url = root.getURL();
if (url.getProtocol().equals("jar")) {
    url = FileUtil.getArchiveFile(url);
// ...
URI rootUri = new URI(url.toExternalForm());
new FileScanner(new File(rootUri),sourceLevel,cb).scan();

Instead, this should be

new FileScanner(root.getURL(), sourceLevel, cb).scan();

and FileScanner should do what it needs to do. ZipArchiveInfo should
accept a second parameter for a JAR entry prefix.
Comment 12 Tomas Hurka 2004-07-26 10:51:26 UTC
*** Issue 46468 has been marked as a duplicate of this issue. ***
Comment 13 Jesse Glick 2004-10-23 00:07:41 UTC
I think this bug is pretty serious. Prevents use of code completion
against JDK 1.3. Maybe also affects all Mac OS X users?

Anyway the fix should be pretty simple as far as I can see.
Comment 14 Tomas Zezula 2004-10-25 16:00:30 UTC
This is not so easy as Jesse explained, but I will try to fix it.
Comment 15 Martin Matula 2004-10-25 16:07:55 UTC
Thanks Tomas!
Comment 16 Tomas Zezula 2004-10-25 19:09:15 UTC
Checking in javacore/src/org/netbeans/modules/javacore/;
new revision: 1.70; previous revision: 1.69
Processing log script arguments...
More commits to come...
Checking in
new revision: 1.12; previous revision: 1.11
Checking in
new revision: 1.3; previous revision: 1.2
Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.2; previous revision: 1.1
Comment 17 Quality Engineering 2007-09-20 09:56:13 UTC
Reorganization of java component