JNI - question about jmethodid values.

[Peter Hull]

Hi Thomas,
Thank you very much for the detailed explanation. For your
information, the relevant NetBeans bug is
https://issues.apache.org/jira/browse/NETBEANS-1428

On Sat, Nov 24, 2018 at 3:41 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> A jmethodid is a pointer to malloc'ed memory.
OK. Just in case I haven't understood it - does this mean a jmethodid,
once 'created', won't change (after garbage collection or whatever)?
>
> But it is not guaranteed to work. I would probably rather use a
> hashmap or similar.
I need to look at the implications on more detail but think it would
make sense to use long/jlong instead of int/jint on all platforms; the
extra memory use shouldn't be a problem. I think the IDs are just
stored on the Java side and used to get the method name and signature
later. That should be a loss-free cast, shouldn't it?
>
> If this is
> true, this 4x30bit assumption may actually have worked before jdk8,
> since the java heap is allocated as one continuous space, with the
> PermGen clustered in one part of it.
Indeed we did only start to get crashes on JDK9 and later (only
observed on Windows, macOS seems OK and other platforms have not been
tested)

Yours sincerely,
Peter