inconsistent class lookup in native code

Johan Vos johan.vos at
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
as follows:
    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
ClassForName:"" withEnv:jEnv];

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 changes.

- Johan

More information about the openjfx-dev mailing list