[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    inconsistent class lookup in native code
From:       Johan Vos <johan.vos () gluonhq ! com>
Date:       2018-12-19 7:18:28
Message-ID: CABxFH2GD3GnoL7S31xSA3bNC=s_JYLydUMvKsS_-WKYuFrTDaw () mail ! gmail ! com
[Download RAW message or body]

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:"com.sun.glass.ui.mac.MacApplication" 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",
"(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;");
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.

- Johan
[prev in list] [next in list] [prev in thread] [next in thread]