Hi Antonio, Am Dienstag, den 06.04.2021, 23:24 +0200 schrieb antonio: > In which module is System.loadLibrary being invoked? Does that module > depend on any other module that exports the class
The JPMS module is the UNNAMED module (we load OpenJFX on the classpath), for NetBeans modules the module loading the native library is org.netbeans.libs.javafx (with the help of org.netbeans.libs.javafx.linux). > "com/sun/webkit/FileSystem"? Is that class exposed in a public API? Yes I modified the org.netbeans.libs.javafx module to export that class and verified, that I can get a reference to that class and the target method via reflection when called from my test netbeans module. > > El 6/4/21 a las 22:36, Matthias Bläsing escribió: > > At that point the native code tries to load the class > > com.sun.webkit.FileSystem via JNI Env FindClass. > > > > In this case it fails because this code path is invoked from a new > > native thread and thus java falls back to this loading procedure > > I don't think the thread being invoked by a native thread has nothing to > do. My rationale (that is probably wrong, corrections welcome :-): > > a) The native code/native thread tries to load the class using FindClass > on a JNIEnv. > > b) This "JNIEnv" is: > > JNIEnv* env = WTF::GetJavaEnv(); > > (https://github.com/openjdk/jfx/blob/e0ce73a3c8d82d3274bd10799b530f397a90ba60/modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp#L46) > > c) Which in turn uses a "jvm" instance: > > jvm->GetEnv(&env, JNI_VERSION_1_2); > > (https://github.com/openjdk/jfx/blob/e0ce73a3c8d82d3274bd10799b530f397a90ba60/modules/javafx.web/src/main/native/Source/WTF/wtf/java/JavaEnv.h#L43) > > d) And this "jvm" instance is populated on JNI_OnLoad (this is invoked > when System.loadLibrary is being invoked) > > jvm = vm; > > (https://github.com/openjdk/jfx/blob/e0ce73a3c8d82d3274bd10799b530f397a90ba60/modules/javafx.web/src/main/native/Source/WTF/wtf/java/JavaEnv.cpp#L133) > > e) And from > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html > > If FindClass is called from a library lifecycle function hook [which is > the case, as JNI_OnLoad is being called], the class loader is determined > as follows: > > for JNI_OnLoad and JNI_OnLoad_L the class loader of the class that > is loading the native library is used This is not true here. FindClass is not invoked from a lifecycle hook. In this case FindClass is invoked from a new native thread, that is spun up by webcore (webkit) itself. That native thread is independend of the JVM and can call into the JVM via JNI (via the invocation interface), but then the quoted section of the documentation takes effect: Since JDK 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. Here is the stack trace for it (from hs_err_pid*): Stack: [0x00007fa41ce47000,0x00007fa41d646000], sp=0x00007fa41d6449c0, free space=8182k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x91203a] jni_CallStaticBooleanMethodV+0x7a C [libjfxwebkit.so+0x5fd155] JNIEnv_::CallStaticBooleanMethod(_jclass*, _jmethodID*, ...)+0x85 C [libjfxwebkit.so+0x2a0d82a] WTF::FileSystemImpl::makeAllDirectories(WTF::String const&)+0xda C [libjfxwebkit.so+0x553707] WebCore::StorageSyncManager::fullDatabaseFilename(WTF::String const&)+0x27 C [libjfxwebkit.so+0x54e83a] WebKit::StorageAreaSync::openDatabase(WebKit::StorageAreaSync::OpenDatabaseParamType)+0x3a C [libjfxwebkit.so+0x54f8a9] WebKit::StorageAreaSync::performImport()+0x29 C [libjfxwebkit.so+0x553f04] WebCore::StorageThread::threadEntryPoint()+0xb4 C [libjfxwebkit.so+0x29aa793] WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+0x63 C [libjfxwebkit.so+0x2a1253d] WTF::wtfThreadEntryPoint(void*)+0xd There is no native frame and thus even if the thread itself would be attached to the JVM as suggested in your second email, it would still be missing a context to find that invoking java method and its class loader. Greetings Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
