harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glyn Normington <g...@apache.org>
Subject Re: [drlvm] The Return of the Hidden Classloader, Part II
Date Wed, 07 Feb 2007 13:00:33 GMT
"Alex Blewitt" <alex.blewitt@gmail.com> wrote on 07 Feb 2007 08:59:33 GMT:

 > On 07/02/07, Yang Paulex <paulex.yang@gmail.com> wrote:
 > > 2007/2/7, Geir Magnusson Jr. <geir@pobox.com>:
 > > >
 > > > We never solved the problem of how to hide non java*. packages that
 > > > are on the boot classpath from apps.  We talked about a few
 > > > possibilities :
 > > >
 > > > 2) have a "hidden" classloader that only the system classloader 
can use.
 > > >
 > > > I like #2.  Has anyone looked into this or made any progress?  Do
 > > > people think this is as important as I do?
 > >
 > > +1, the hidden classloader so far seems a better way to go, but for 
long
 > > term, I wish the JSR 277[1] or JSR 291[2] can be considered to 
address this
 > > kind of issue in general.
 >
 > IIRC JSR277 doesn't have the concept of classloaders, so this wouldn't
 > work. It only enforces modularity at compile time, at least, for my
 > understanding.

JSR 277 will have a class loader for each runtime instance of a 
"deployment module". Compile-time enforcement of "development modules" 
will be in JSR 294. Both in Java 7...

 >
 > JSR 291 (OSGi) of course solves this problem, and given that Harmony
 > is being put together as a suite of bundles, would probably make sense
 > to at least emulate. Equninox uses a classloader to do load all the
 > main ones and decide whether or not to pass things up to the parent
 > classloader. You could then set this as the thread's context
 > classloader; but I don't know how that would work for e.g. newly
 > created threads.
 >
 > PS there's a bunch of config options that you can specify to configure
 > what the osgi classloader does:
 >
 > http://wiki.eclipse.org/index.
 > php/FAQ_How_do_I_add_a_library_to_the_classpath_of_a_plug-in%3F
 >
 > "setting the osgi.parentClassloader system property on startup ... to
 > one of boot, ext, app or fwk."
 >
 > These configure what items are visible from the classloader.

We considered using a Java OSGi framework, like Equinox, to implement 
base class library modularity for Harmony, but there are some nasty 
issues due to the dependencies of a Java framework on the base class 
libraries.

For example, suppose the framework depends on a class X from the base 
class library. Then loading X will tend to cause an infinite recursion.

This sounds like a rare case, but existing OSGi frameworks use a fair 
number of base classes spread across multiple Harmony components. To 
avoid such recursions, the VM would need to load a sufficient, 
self-contained subset of base classes to support the framework before 
allowing the framework to run. Since this subset is spread across 
multiple components, the JVM would have to implement the required 
framework function, thus obviating the need for the framework. Also, the 
framework would have to adhere to this subset - which would be hard to 
enforce if we picked up the framework from an independent open source 
project like Equinox.

So the workable alternatives would be to (fork and) maintain a suitable 
Java framework in Harmony or to put the necessary function into the JVM. 
We are currently experimenting with the latter approach as it side-steps 
other sources of infinite recursion (of which there are many - we 
atually tried the Java framework approach for a while).

Glyn


Mime
View raw message