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 Thu, 09 Jun 2005 19:42:42 GMT
On 6/9/05, Richard S. Hall <heavy@ungoverned.org> 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.

Mime
View raw message