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
