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 48280 - Inter Project Go To Declaration/Source Problem in NB 4.0
Summary: Inter Project Go To Declaration/Source Problem in NB 4.0
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: PC OS/2
: P4 blocker (vote)
Assignee: Tomas Zezula
Depends on:
Blocks: 41537 44367
  Show dependency tree
Reported: 2004-09-01 08:55 UTC by lkishalmi
Modified: 2008-12-22 17:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

The stack trace of NPE (2.25 KB, text/plain)
2004-09-01 18:28 UTC, lkishalmi
Dumb, but working patch (2.00 KB, text/plain)
2004-09-02 11:23 UTC, lkishalmi
The patched URL handlers (8.84 KB, application/octet-stream)
2004-09-05 22:56 UTC, lkishalmi
The proposed solution of patched URL handlers (2.85 KB, text/plain)
2004-09-05 22:58 UTC, lkishalmi
Proposed patch no borrowed code from JRE. (7.06 KB, application/octet-stream)
2004-09-13 12:44 UTC, lkishalmi

Note You need to log in before you can comment on or make changes to this bug.
Description lkishalmi 2004-09-01 08:55:28 UTC
I've noticed recently, that Go To Source action
does not work when the required source code is not
in the current project, but in a one which is
opened and the current project is depending on.


Project A: (depends on Project B)
    Class A1 (depends on Class A2 and Class B1)
    Class A2
Project B:
    Class B1

If I'm editing Class A1, Class A2 can be opened
with Alt+O, but the same  Alt+O results "Source
Class B1 not found" dialog on Class B1. However,
Go to source works with external libraries.

I think the problem is somewhat deeper in the
infrastructure as the breakpoints set on Class B1
are ignored when you debug Project A.
Comment 1 Jesse Glick 2004-09-01 16:35:55 UTC
Working fine for me in a current dev build; Alt-O jumps between the
projects, no problem. Reopen if you can attach precise steps to
reproduce the problem from scratch - i.e. fresh NB installation, fresh
user dir, newly created projects.

Inter-project breakpoints are working for me too, BTW.
Comment 2 lkishalmi 2004-09-01 18:21:57 UTC
I've tested this issue again (2004-Aug-31 build). It works on Solaris,
but fails on OS/2, So I altered the OS, and lowered the priority of
this issue to P4.
I think the solution could be quite trivial. 

With the 2004-Aug-31 build Alt-O gives an exception if the project
dependencies has not been set. In this case the stack trace is the
same on Solaris and on OS/2. If I set the dependency the Alt-O works
on Solaris, but still give the same stack trace on OS/2 as before.

I try to debug it further.
Comment 3 lkishalmi 2004-09-01 18:28:07 UTC
Created attachment 17295 [details]
The stack trace of NPE
Comment 4 lkishalmi 2004-09-01 19:31:18 UTC
I've debugged the NPE and filed issue #48332 against the editor code.
Comment 5 Jesse Glick 2004-09-01 20:01:07 UTC
OK, but if it is not reproducible on a platform supported by Sun's QA,
I probably can't do anything with it.

Is there any case where the exception is not thrown, but Alt-O
nonetheless does not work? If not, this is simply a duplicate of issue

In any case I doubt the bug is in the projects component, but without
more information it is hard to know what is responsible for it.
Comment 6 lkishalmi 2004-09-01 21:04:12 UTC
Further debuging the problem it has turned out that NPE was only
thrown, when I pressed Alt-G on a class which was not in the scope of
the Code Comletion Engine (Missing forom the parser DB (if it still
exists?) Or MDR.) The reason why it is missing is unknown to me. Other
classes from the same package are on the list.

Debugging with a class which is in the scope of CC I guess that the
probem is either in javacore or in java/api. But to reveal the problem
I have to place some debug code and rebuild the java/api module. 
Comment 7 Jesse Glick 2004-09-01 21:19:09 UTC
Great! Obviously information at the source code level would be
especially helpful, if the problem cannot be easily reproduced on more
common platforms.
Comment 8 lkishalmi 2004-09-02 11:14:31 UTC
Finnally I've got it! It's most likely a JAVA 1.4.1 related problem,
however I couldn't manage to test it on 1.4.2_05 as that JVM gave me
worse exceptions than before.

The guilty is the following:

in method hasSources(URL, String) has a comparison between two URLs:

url.equals(binaryRoot) returns with false even the path and the
handler is the same.

I've changed this to url.toString().equals(binaryRoot.toString()) and
tested the IDE again. It seems this could be a solution.
Comment 9 lkishalmi 2004-09-02 11:23:42 UTC
Created attachment 17313 [details]
Dumb, but working patch
Comment 10 Jesse Glick 2004-09-02 15:50:43 UTC
OK, so now the questions are:

1. Why is OS/2's JDK not correctly implementing URL.equals? Does the
1.4.2 port fix this? Has the problem been reported?

2. What other important code is using URL.equals that might also be
broken on OS/2 (or on JDK 1.4.1)?

Note that generally we do not support JDK 1.4.1.

BTW prefer URL.toExternalForm to URL.toString for stylistic reasons.
Comment 11 lkishalmi 2004-09-02 18:40:30 UTC
I've created a simple program just to test the URL.equals function.
It seems that only the OS/2 1.4.1 JVM is guilty fails on the following

  1. Assume that the working directory is D:\develop and has a
prog.jar in it.
  2. URL u1 = new File("prog.jar").toURI().toURL();
  3. URL u2 = new URL("file:/D:/develop/prog.jar");
  4. u1.equals(u2) returns false;
  5. u1.toString().equals(u2.toString()) returns true;

I've tested this on the following JVMs: 
  - OS/2 GoldenCode JVM 1.4.1_06 - FAIL
  - OS/2 InnoTek JVM 1.4.2_05    - PASS
  - WIN32 Sun JVM 1.4.1_03       - PASS

I've sent a mail to GoldenCode. Usually they are quite frendly and
Comment 12 lkishalmi 2004-09-02 23:15:10 UTC
I'm sorry I was wrong with the WIN32 JVM the test passed on 1.4.2_04,
but failed on 1.4.1_03. (I've mixed up the Javahomes.)

GoldenCode ensured that the the test fails on their new JVM 1.4.1_07
as well on the SUN 1.4.1_07 JVM. So finally it is a JDK 1.4.1 issue. :(

I'll try to ask the refactoring module in NB4.0 or RefactorIT where
the URL.equals is used.
Comment 13 lkishalmi 2004-09-03 09:47:47 UTC
Another idea to fix the URL.equals problem is to replace the original
URL handlers in case 1.4.1 JDK to custom ones. It might give a better
fix for issue #44367 as well. I will work it out.
Comment 14 Jesse Glick 2004-09-03 21:23:59 UTC
That could help, though it would also be pretty risky I think; the JAR
URL handler is not trivial.
Comment 15 lkishalmi 2004-09-05 00:18:01 UTC
I've managed to fix the "file" protocol handler. The problem was the
following. File.toURI().toURL() gave host as null, but URL(<url>)
parses host as "". 

The jar problem is really not that easy. The NPE comes only when the
URL connection was opened without jar file caching. It also could have
been solved relative easily if the implementator of the original code
had not changed the visibility of the jarFileURLConnection instance
variable from protected to private.

Borrowing code from the JDK ( I solved that
problem too. What are the licensing issues about this?
Comment 16 lkishalmi 2004-09-05 22:56:22 UTC
Created attachment 17377 [details]
The patched URL handlers
Comment 17 lkishalmi 2004-09-05 22:58:29 UTC
Created attachment 17378 [details]
The proposed solution of patched URL handlers
Comment 18 lkishalmi 2004-09-05 23:07:11 UTC
So I've attached the patched URL stuff. I've created a package under
org.netbeans.core for it (the contents of the zip file), and pathced
NbURLStreamHandlerFactory to use new classes in case of 1.4.1 JRE.
I've also removed the previous patch of issue #44367 from it.

Jesse, would you review it?
Comment 19 Jesse Glick 2004-09-07 18:40:48 UTC
Sorry, we can't accept any code copied from the JDK. It violates the
JDK's license. All NB code must be written from scratch.
Comment 20 lkishalmi 2004-09-09 11:56:51 UTC

I'm rewriting the JarURLConnection from scratch, leave the
JarFileFactory out. The patched URL handler only routes the jar
protocol which uses 'file' internal protocol to the new
implementation, so it would ben not that hard and risky.
Comment 21 lkishalmi 2004-09-13 12:44:49 UTC
Created attachment 17576 [details]
Proposed patch no borrowed code from JRE.
Comment 22 lkishalmi 2004-09-13 13:01:57 UTC
I've rewritten the JarURLConnection, so there in no borrowed from the
JDK required. I've tested it as far as I can it works even when I
forced the URL cache.
Comment 23 Jesse Glick 2004-09-13 15:42:31 UTC
Do you have a complete patch which would conditionally install these
URL handlers only on JDK 1.4.1? I guess that would be the last two
attachments (patch48280_2.diff +, but please confirm;
best to attach only complete patches, just to be sure.


  private boolean j2se141 = ...;

could be

  private static final boolean J2SE_141 = ...;

for stylistic reasons.

Just FYI: there is no need to write

/** {@inheritDoc} */

since you can just omit the Javadoc comment entirely and it will work
the same way.

Tomas: Leslie (Laszlo?) has a signed JCA.
Comment 24 lkishalmi 2004-09-13 16:15:54 UTC
Yes you are right patch48280_2.diff and is the
complete patch. I couldn't create complete patch as the zip file
contains a different java package for URLHandlers. (cvs diff -u -N
does not work here.)

The /** {@inheritDoc} */ is a "bad" habit. We are using checkstyle at
work which accepts {@intheritDoc} but generates error if javadoc is

private static final boolean J2SE_141 = ...;
I agree.
Comment 25 lkishalmi 2004-09-13 16:21:08 UTC
BTW: JCA has been signed already.
Comment 26 lkishalmi 2004-09-22 17:30:39 UTC
Tomas, could you integrate it?
Comment 27 Tomas Zezula 2004-09-29 16:10:25 UTC
The patch is fine, I will integrate it.
Comment 28 Tomas Zezula 2004-09-30 13:39:09 UTC
I've applied the Leslie's patch.

Checking in src/org/netbeans/core/;
/cvs/core/src/org/netbeans/core/,v  <--
new revision: 1.9; previous revision: 1.8
Processing log script arguments...
More commits to come...
RCS file:
Checking in
initial revision: 1.1
RCS file:
Checking in src/org/netbeans/core/jse141urlpatch/;
initial revision: 1.1
RCS file:
Checking in src/org/netbeans/core/jse141urlpatch/;
initial revision: 1.1
RCS file:
Checking in
initial revision: 1.1
Comment 29 lkishalmi 2004-10-01 23:01:22 UTC
Verified on 20040930 build. It works!
Thanks for the integration!