What does FML to the ClassLoader?

[BuildLight]

Hello everyone!

While working on my chromium API/mod https://github.com/montoyo/mcef I've been playing with the JNI (Java Native Interface) a lot. It works pretty well while you keep playing on a Java-created thread; but if you need to create an object from a native thread and pass it to your FML mod... well, you get some weird exceptions: cannot cast class into the same class, incompatible class change exception, abstract method call exception, etc...

This happens when, for instance, you create an object from your C/C++ thread using env->FindClass(), and then passes it to a java method. Sometimes env->FindClass might fail and throw a ClassNotFoundException, or sometimes all the native part works but when using the object from Java it throws one of the exceptions I named before. By the way, I say it happens only with a FML mod because actually it works with a normal Java app.

So I have two questions:

1. Obviously FML changes things on the ClassLoader to load mods; can anyone tell me what and how it works?

2. I've fixed those bugs by calling ClassLoader.loadClass() from my native but this is probably very slow... any idea how else I could fix this?

Thanks a lot,

- BuildLight (aka montoyo)

[Sessional]

Does this have to do with the reobfuscation process by any chance? I haven't worked with JNI and definitely don't have much experience with Forge or FML, but when you build your (at least Forge?) project it does some renaming to put all the methods and classes back in to different names that are normally found inside the minecraft jar file.

 

There's an MCPBot link floating around somewhere that has the mappings if you want to give it a shot.

[BuildLight]

As far as I know, only Minecraft's classes/methods/fields are renamed by forge's reobfuscation; so my classes remains unmodified. And since my native only make calls to my own mod, I doubt that it's forge's reobfuscation

I think that forge changes the default class loader whereas JNI's env->FindClass keeps the system's one. Is there any way to change the JNI's class loader?

[diesieben07]

The documentation says FindClass uses the classloader of the class that the JNI method is located in.

So... if the JNI class and the class you're trying to access are in the same jar file, it should work.

[BuildLight]

Thanks for the link to the documentation, I now have my answer... the doc says:

Since Java 2 SDK release 1.2, the Java security model allows non-system classes to load and call native methods. FindClass locates the class loader associated with the current native method; that is, the class loader of the class that declared the native method. If the native method belongs to a system class, no class loader will be involved. Otherwise, the proper class loader will be invoked to load and link the named class.

 

Since Java 2 SDK release 1.2, when FindClass is called through the Invocation Interface, there is no current native method or its associated class loader. In that case, the result of ClassLoader.getSystemClassLoader is used. This is the class loader the virtual machine creates for applications, and is able to locate classes listed in the java.class.path property.

 

That's why it works when Java calls natives and not when natives calls Java  . Thanks.

Now, second question: how to handle this (at least, how to handle this quicker than I actually do)? Can I override the system class loader with forge's one?

[diesieben07]

I googled a bit and the only solution I found was: make a pure java method that returns the correct class and invoke that from the native code.

[BuildLight]

Mhhhh okay, probably faster. Thanks!