[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Loading native libraries
From: |
Archie Cobbs |
Subject: |
Re: Loading native libraries |
Date: |
Fri, 4 Jun 2004 09:11:47 -0500 (CDT) |
Jeroen Frijters wrote:
> Archie Cobbs wrote:
> > > I think we desperately need a VMClassLoader.getCallerClassLoader()
> >
> > But what the semantics of this method? I.e., define the "caller".
> >
> > For example, would it return the same thing for both of these
> > call traces?
> >
> > Foo.method -> Runtime.loadLibrary()
> > Foo.method -> System.loadLibrary() -> Runtime.loadLibrary()
>
> No magic. It always returns the caller. We would simply modify
> System.loadLibrary to call Runtime.loadLibraryImpl(String libname,
> ClassLoader loader) (or whatever).
You're saying it's equivalent to "VMSecurityManager.getClassContext()[1]" ?
There are several instances of that expression in Classpath, so this
optimization may indeed be useful. (This is an orthogonal issue from
the one I originally asked about, but I agree with you).
But what about:
Foo.method()->Method.invoke()->Runtime.loadLibrary()->getCallerClassLoader()
Is the "caller's" class supposed to be "Foo" or "Method" ? This is something
that is not made clear in the documentation to getClassContext().
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com