"Alex Blewitt" <[EMAIL PROTECTED]> wrote on 07 Feb 2007 08:59:33 GMT:
> On 07/02/07, Yang Paulex <[EMAIL PROTECTED]> wrote:
> > 2007/2/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> > >
> > > 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
