On 6/9/05, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Rodrigo Kumpera wrote: > > >OSGi is really nice to work, but I doubt it can be used within the > >class library. Most code except that a JVM will create at most 2 > >classloader, the bootstrap classloader (which can be null) and the > >application classloader. > > > > > > I actually thought there were three: Bootstrap, extension, and application. > > I am not sure why this is an issue, though. Does the spec require this? > It sounds like an implementation detail to me. > > Also, I am not saying that we directly use OSGi, just something that has > some of the capabilities that OSGi demonstrates. > > -> richard >
AFAIK the term extension classloader is used for application created classloaders. The application classloader handles classpath and installed extends (the dreaded /lib/ext directory). In terms of extensibility, the classlib is mostly a dead-end, an end-user should be better using some SPI. But good modularity keeps the software entropy low. I think a build time "good citizenship" test can do just fine, so no module mess with other's internals unless it's specified. Having export/import controls for the public API (the j2se api) seens allmost unreasonable. But if the JVM is build all in java, or big chunks at least, using an OSGi like thing is a very good idea for managing the implementation.
