Support context class loader in NativeRuntime's closureManager about jnr-ffi

[mkristian]

will have look into this first thing next year :)

[btiernay]

I was able to work around this issue by doing the following:

    ClosureManager closureManager = NativeRuntime.getInstance().getClosureManager();
    val classLoader = findField(closureManager.getClass(), "classLoader");
    classLoader.setAccessible(true);
    val asmClassLoader = classLoader.get(closureManager);

    val parent = findField(asmClassLoader.getClass(), "parent");
    parent.setAccessible(true);
    parent.set(asmClassLoader, Thread.currentThread().getContextClassLoader());

[mkristian]

this means when we switch to the context classloader that in OSGi case it can not find its classes since OSGi does not work with context classloader at all.

but probably you are right in the respect that ClassLoader.getSystemClassLoader() is not the right thing. I would say that getClass().getClassLoader() is the better choice which will work when everything is loaded from the context classloader and with the OSGi case as well.

[btiernay]

That would be a better default. Also, would it be possible to make this configurable maybe?

[headius]

See contributed test case in #55.

[neupsh]

Is there any update on this issue? I was trying to use jnr related java library in clojure and when i run the project with boot-clj build tool, it fails to load the class with:

java.lang.ClassNotFoundException: jnr.ffi.provider.jffi.NativeClosureProxy
             java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/NativeClosureProxy
                 java.lang.RuntimeException: java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/NativeClosureProxy

This is because, boot-clj runs 'boot-tasks' in 'pods', which are clojure runtimes in single JVM. They are separated by different classloaders and thus the dependencies are tied to these different classloaders. The System ClassLoader does not have any libraries in the classpath and as a result, it fails to load the class.

[headius]

Let's try fixing this with getClass().getClassLoader() falling back on ClassLoader.getSystemClassLoader() when that is null. I'll commit that and y'all can test it.

[headius]

I've pushed a fix and will release 2.1.3 shortly.

[gzunino]

This is not enough for OSGi running jnr as bundle, when a closure defines a return type with a Class defined in another bundle. For example:

BundleA > BundleJNR (BundleA depends on BundleJNR)

a callback on BundleA with a return type ClassA, being ClassA a class on BundleA.

JNR tries to load ClassA with the classloader of BundleJNR and fails to do it.

[realPyR3X]

Has this issue been resolved for OSGi? I'm trying to use JavaFS which relies on this library and I continue to get The activate method has thrown an exception

The activate method has thrown an exception java.lang.RuntimeException: java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/AsmStructByReferenceFromNativeConverter