|
Evaluation
|
The system classloader is obtained through ClassLoader.getSystemClassLoader() during JVM initialization. By the time this is invoked, the native module launcher has not yet passed along all the module launching information (e.g. module name, repository name, etc.) to the JVM. Because of the lack of information, the module classloader cannot be created on demand and to be set as the system classloader at that point.
To fix this, the native launcher code will need to be rearranged and pass the information to the JVM side as system properties, so the module classloader can be created on demand when the ClassLoader.getSystemClassLoader() is called during JVM initialization.
Posted Date : 2007-09-13 00:14:38.0
See comments.
Posted Date : 2007-09-13 00:30:07.0
I don't follow the logic. The class loader of the module being launched is not available until that module has completed initialization. Module initialization involves execution of lots of Java code, e.g. the entire networking stack in case of a URLRepository. Having the launcher native code populate something like system properties does not solve that.
If the creation of the system class loader cannot be delayed, then it should be created as a ClassLoader that initially always throws ClassNotFoundException and after the module becomes available delegates to that module class loader.
Note that this bug will also need to update the implementation of the classpath module, since currently that just delegates to the system classloader.
Posted Date : 2007-09-13 00:38:42.0
|
