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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
