classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading native libraries


From: Dalibor Topic
Subject: Re: Loading native libraries
Date: Fri, 04 Jun 2004 16:53:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421

Archie Cobbs wrote:
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().

Foo, I believe.

Otherwise all reflection would happen with the security credentials of java,lang.reflect, and that would be a bad thing, I guess.

cheers,
dalibor topic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]