On 6/10/05, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Rodrigo Kumpera wrote: > > >AFAIK the term extension classloader is used for application created > >classloaders. The application classloader handles classpath and > >installed extends (the dreaded /lib/ext directory). > > > > > > Well, just writing a simple program that prints the class loaders, I get: > > loader = [EMAIL PROTECTED] > loader = [EMAIL PROTECTED] > loader = null > > Where the "null" represents the bootstrap class loader, so I still count > three, but I don't think this adds much to the discussion. :-) > > >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 am not sure what you are referring to with "classlib" here.
The j2se lib, eg what classpath is implementing. > > >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. > > > > > > Build-time test? What about code compiled by another compiler? This > doesn't make much sense to me. If we are talking about Java, then every compiler should produce the same stuff, class files. My suggestion is to have a after-compilation step. > >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. > > > > From my experience, it makes sense, period. > > -> richard > Well, the classpath folks seen to be doing just fine without an OSGi like container. There are some implications for building such thing, first is the fact that a big part would need to live in a "container-less" enviroment, as it would be hard to read a manifesto file without the java.io package available. ;) Big parts of the classlib is implemented throu service providers, may be they should be developed separated from the lib itself.
