inconsistent class lookup in native code
johan.vos at gluonhq.com
Wed Dec 19 07:18:28 UTC 2018
I noticed the behavior in the native-glass code for calling back in the
Java layer differs fundamentally between linux and mac.
On Linux, the JNI_OnLoad call will initialize the required
classes/methods/fields for calling back into Java, and class lookup is done
clazz = env->FindClass("com/sun/glass/ui/gtk/GtkApplication");
On Mac, however, the lookup is done via calls to a GlassHelper, e.g.
jclass cls = [GlassHelper
Inside the GlassHelper, the java.lang.Class is looked up via JNI code, and
then a Java call to Class.forName() is done:
jclass jcls = (*env)->FindClass(env, "java/lang/Class");
forNameMID = (*env)->GetStaticMethodID(env, classCls, "forName",
jclass foundClass = (*env)->CallStaticObjectMethod(env, classCls,
forNameMID,classNameStr, JNI_TRUE, glassClassLoader);
I wonder why there is a difference between linux and mac here?
In general, I see similar code between the linux/mac native directories.
Most code that leads to callbacks into the Java layer is very similar.
Therefore, I think for long-term maintainability, we might benefit from
having a native-glass/share directory where most of this shared code can
reside in (similar to the share/native directory in OpenJDK modules). This
would prevent having to change all implementations if something in the
low-level (private) API of javafx.graphics changes.
More information about the openjfx-dev