harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: [modules] Packaging Class Libraries
Date Fri, 10 Jun 2005 12:06:53 GMT
On 6/10/05, Richard S. Hall <heavy@ungoverned.org> 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 = 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.

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

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

View raw message