JNI changes for modules

[Florian Weimer]

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