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.
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.
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
