harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: [drlvm] The Return of the Hidden Classloader, Part II
Date Wed, 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 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.

Alex.

Mime
View raw message