JNI - question about jmethodid values.

[coleen.phillimore at oracle.com]

On 11/28/18 10:08 AM, Thomas Stüfe wrote:
> On Wed, Nov 28, 2018 at 4:03 PM <coleen.phillimore at oracle.com> wrote:
>>
>>
>> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
>>> On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>>> Hi Coleen,
>>>>
>>>> (moved to svc-dev since David did shoo us off discuss before :-)
>>>>
>>>> Just to be sure I understand:
>>>>
>>>>> If the class is unloaded, the jmethodID is cleared.  Native code should
>>>>> first test whether it's NULL.  I think that is the predictable behavior
>>>>> that the spec requires.
>>>> Wait, really? So, As a JNI caller I should do this:
>>>>
>>>> jmethodID method;
>>>> ..
>>>> if (*method == NULL) { .. invalid method id .. }  ?
>>>>
>>>> I thought jmethodid is opaque, and its value itself cannot be changed
>>>> from the VM, no?
>>>>
>>> Oh you probably meant "native code in the VM", not "native JNI code".
>>> Sorry for the confusion.
>> I did mean native JNI code, but I actually don't know how native JNI
>> code is supposed to deal with nulled out jmethodIDs.
>>
>> Maybe they predictably crash?
>>
>> Coleen
> I always thought  it would gracefully reject, e.g. on JVMTI with
> JVMTI_ERROR_INVALID_METHODID.
>
> Save that JC wrote that there are some JNI function sequences where
> the VM would still crashes:
>
> <quote jc>
>     - Get a jmethodID and remember it
>     - Wait until the class gets unloaded
>     - Get the class to get reloaded and try call the old jmethodID
> (which now points to NULL), the code will segfault
> </quote>
>
> which looks like just a bug to me.

It may be misuse of JNI also.  We don't guarantee a lot of things with 
JNI.  Maybe instead of clearing, we could install a Method* that throws 
NSME.

But I guess why leak the jmethodID memory if it's going to crash anyway 
when using it?

Coleen

>
> ..Thomas