RE: [cp-patches] Native library class loader fixes

[Jeroen Frijters]

Archie Cobbs wrote:
> OK. I suppose it makes sense to move getClassContext() there 
> too, and get rid of VMSecurityManager.java (which will become
> empty), as these methods are all now going to be used more
> generally than just for SecurityManager stuff.
> 
> I also noticed that VMSecurityManager.currentClassLoader() is 
> completely unecessary, and removed it.
> 
> New patch attached. Let me know what you think.

Thanks. I implemented it with IKVM and it allowed me to remove my own
stack walking workaround in my JNI code. Everything seems to work.

I made one change to your patch (in loadLibrary in Runtime.java):
+    else
+      {
+       filename = VMRuntime.mapLibraryName(libname);
+       for (int i = 0; i < libpath.length; i++)
+         if (loadLib(libpath[i] + filename, null) != 0)
+           return;
+      }

I think the second argument to loadLib() should be "loader" instead of
null. It's a bit counterintuitive, but my understanding is that a native
library always gets associated with the class loader of the class that
called loadLibrary (regardless of whether the class loader was otherwise
involved in finding/loading the library).

I've also attached a patch for ResourceBundle to use the new
getCallingClassLoader instead of it having it's own private hack. We
might be able to get rid of ObjectInputStream.currentClassLoader() as
well.

Regards,
Jeroen

ResourceBundle.patch.txt
Description: ResourceBundle.patch.txt