As I try to put together some netbeans modules for Jini development tasks, I am
fighting with netbeans classloader use alot (and not actually winning it seems).
So I am thinking (actually I'm trying some of this out) about whether it would
make sense to help with OSGi and other classloader integration as well, if we
could put an SPI in front of the use of RMIClassLoader.loadClass() etc so that
different environments could provide more deliberate control over where classes
are resolved.
The problem I am having in netbeans is that I need the PreferredClassProvider
and jsk-resources.jar which provides the Jini RMIClassLoaderSpi to be in the JVM
system class loader to make it active. Yet that class loader is invisible to
the netbeans module subsystem because it provides brickwall separation of the
modules from each other through separate classloaders that will delegate to the
netbeans system class loader. All of the delegation back and forth is what I am
fighting with.
What I am playing with is creating a static class that mimics the
RMIClassLoaderSpi by providing the same methods, but which then also provides a
security controlled setter to set the implementation. An interface would then
document the methods that this SPI requires, and then implementation of that
interface could be "set" on this static class.
The simple nature of this change means that we can just replace RMIClassLoader
references with the static class reference, and provide a simple implementation
of the interface that just uses RMIClassLoader.xxxx() calls for implementation.
That would put the code in a position to accept pluggable implementations of
class resolution I believe.
However, I'm still trying to think through how PreferredClassProvider and
ClassLoading interact with RMIClassLoaderSPI to see if I've forgotten something big.
I'm curious if anyone from the Jini team at Sun has any insight into whether
this would really make it possible to better control which class loaders are used.
Right now, there are several places in the Jini code where null ClassLoader
references end up redirecting loading into the netbeans context class loader
which is almost always the netbeans system class loader, and I'm having a hard
time keeping the codebase loader visible.
Anyone have thoughts or questions?
Gregg Wonderly
