harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [modules] Packaging Class Libraries
Date Fri, 10 Jun 2005 07:32:32 GMT
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 = sun.misc.Launcher$AppClassLoader@7b7072
    loader = sun.misc.Launcher$ExtClassLoader@136228
    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

Mime
View raw message