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.
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. E.g.: 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.
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.
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.
Created attachment 17295 [details] The stack trace of NPE
I've debugged the NPE and filed issue #48332 against the editor code.
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 #48332. 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.
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.
Great! Obviously information at the source code level would be especially helpful, if the problem cannot be easily reproduced on more common platforms.
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: org.netbeans.modules.java.j2seproject.queries.CompiledSourceForBinaryQuery.java 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.
Created attachment 17313 [details] Dumb, but working patch
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.
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 situation: 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 responsive.
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.
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.
That could help, though it would also be pretty risky I think; the JAR URL handler is not trivial.
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 (sun.net.www.protocol.jar) I solved that problem too. What are the licensing issues about this?
Created attachment 17377 [details] The patched URL handlers
Created attachment 17378 [details] The proposed solution of patched URL handlers
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?
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.
OK. 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.
Created attachment 17576 [details] Proposed patch no borrowed code from JRE.
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.
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 + patch4820_2.zip), but please confirm; best to attach only complete patches, just to be sure. BTW 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.
Yes you are right patch48280_2.diff and patch48280_2.zip 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 missing. On private static final boolean J2SE_141 = ...; I agree.
BTW: JCA has been signed already.
Tomas, could you integrate it?
The patch is fine, I will integrate it.
I've applied the Leslie's patch. Checking in src/org/netbeans/core/NbURLStreamHandlerFactory.java; /cvs/core/src/org/netbeans/core/NbURLStreamHandlerFactory.java,v <-- NbURLStreamHandlerFactory.java new revision: 1.9; previous revision: 1.8 done Processing log script arguments... More commits to come... RCS file: /cvs/core/src/org/netbeans/core/jse141urlpatch/FileURLStreamHandler.java,v done Checking in src/org/netbeans/core/jse141urlpatch/FileURLStreamHandler.java; /cvs/core/src/org/netbeans/core/jse141urlpatch/FileURLStreamHandler.java,v <-- FileURLStreamHandler.java initial revision: 1.1 done RCS file: /cvs/core/src/org/netbeans/core/jse141urlpatch/JarURLConnection.java,v done Checking in src/org/netbeans/core/jse141urlpatch/JarURLConnection.java; /cvs/core/src/org/netbeans/core/jse141urlpatch/JarURLConnection.java,v <-- JarURLConnection.java initial revision: 1.1 done RCS file: /cvs/core/src/org/netbeans/core/jse141urlpatch/JarURLStreamHandler.java,v done Checking in src/org/netbeans/core/jse141urlpatch/JarURLStreamHandler.java; /cvs/core/src/org/netbeans/core/jse141urlpatch/JarURLStreamHandler.java,v <-- JarURLStreamHandler.java initial revision: 1.1 done RCS file: /cvs/core/src/org/netbeans/core/jse141urlpatch/PatchedURLStreamHandlerFactory.java,v done Checking in src/org/netbeans/core/jse141urlpatch/PatchedURLStreamHandlerFactory.java; /cvs/core/src/org/netbeans/core/jse141urlpatch/PatchedURLStreamHandlerFactory.java,v <-- PatchedURLStreamHandlerFactory.java initial revision: 1.1 done
Verified on 20040930 build. It works! Thanks for the integration!