* Mandy Chung: > On 8/21/20 4:42 AM, Florian Weimer wrote: >> I see there's a new GetModule entry point, but I can't find anything >> that interacts directly with it. >> >> The challenge I see is that FindClass often cannot find application >> classes once modules are involved. Technically, I guess that's not a >> new phenomenon and could have happened before once multiple class >> loaders are involved. However, modules seem to encourage such setups >> and expose this functionality to more developers, I suppose. >> >> Is the recommended way to use the jclass parameter of native methods >> with GetModule to obtain the application module, and call >> getClassLoader() and its loadClass(String) methods to get this to >> work? Isn't this a tad bit involved? There's also an asymmetry due >> to the use of source class names, unlike FindClass. > > JNI FindClass is equivalent to calling 3-arg Class::forName using the > loader of the caller class that invokes FindClass. It can find the > classes that are visible to the loader. It will find classes in another > module as long as it's exported to the caller's module.
Ahh. I should have read the JNI spec more closely. This behavior does in fact follow from this clause: | FindClass locates the class loader associated with the current | native method; that is, the class loader of the class that declared | the native method. If the native method belongs to a system class, | no class loader will be involved. Otherwise, the proper class loader | will be invoked to load, link, and initialize, the named class. Maybe it's time to remove the references to JDK 1.1 and JDK 1.2. 8-) > Can you say more about the scenarios what you refer to "FindClass often > cannot find application classes once modules are involved"? I must have had a different bug, sorry. I removed my code which more or less did what FindClass is expected to do, and I don't see any issues anymore.
