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.
Currently we suffer by maintainance nightmare of many different launchers for different platforms that perform a task that could be easily written in Java and made portable. At least the computation of classpath should move out of the launchers and moved to the Java code. For the reasons stated above and also to load the core&openide by our own classloader that will give us better control of what it loads. Resulting in improved performance and compatibility capablilities.
Created attachment 6570 [details] Implementation of the new launcher - changes in runide.sh, build.xml and Main.java
Trung could you think about the issue and if found sufficiently improtant incorporate it into plans for next version?
Issue #20254 is related, maybe a duplicate. I considered doing pretty much what you have here several times and ultimately decided each time *not* to do it. 1. There is a reason some modules put things in lib/ext/. They need to be in the startup classloader. *Not* some classloader that the core happens to be loaded from. 2. Most of the complexity in the launchers is in various weird things that we cannot fix this way. Creating the classpath is relatively pretty easy. Maintenance of launchers will still be tough. 3. There is no more compatibility/safety argument for doing this, after the fix of issue #19622. 4. I'm not sure what your performance argument is. There might be an improvement, but there might also be a performance regression from loading more classes from a non-startup loader. 5. Did you check whether AU still works?
Ok, I see. Ad. 1 - I do not care much about lib/ext, what I really need is to load openide and core by my classloader. Do you think that I could add lib/ext to classpath by the runide.sh, move lib/boot/boot.jar into lib/ext/boot.jar and remove lib/ext directory checking from the org.netbeans.Main? I do not see all implications, so I am not sure what would be broken then? Ad. 2 - According to Petr Nejedly by using ProxyClassLoader for core & openide we can get rid of a lot of ClassNotFoundException as we did for modules.
Re. loading openide/core in a special classloader - lib/ext/boot.jar should work, I guess. Re. performance enhancement of not having core.jar and openide.jar in the startup classloader - OK maybe it will help, it would be worth measuring. Generally PCL is most useful for performance in that if PCL1 delegates to PCL2 delegates to some random CL, then a missing class will only throw CNFE from the random CL and then from PCL1, but not from PCL2 (which just returns null). loadClass from outside code must throw CNFE, and loadClass on non-PCL CL's will throw CNFE too; only PCL -> PCL communication is optimized. I am not sure if the optimization would be triggered here... but check up on it. The speed of #19622 needs to be investigated too, probably, to make sure overhead is low. Especially as more modules add OpenIDE-Module-Public-Classes declarations.
The PCL(openide+core) will reduce the number of CNFEs by skipping the call to the parent classloader for already known packages, that is to about 3 CNFEs + some EmptyStack + some PrivilegedAction per package. Anyway, the gain won't be that big as we've already collected the low hanging fruit.
Target milestone was changed from '3.4' to TBD.
The implementation of this issue is part of work on issue 26126 If we merge all work done on patchbytecode_26126branch wihout the actuall patching we will get the java launcher. *** This issue has been marked as a duplicate of 26126 ***