Review Request JDK-8188052: JNI_FindClass needs to specify the class loading context used for library lifecycle hooks
David Holmes
david.holmes at oracle.com
Thu Oct 5 00:44:32 UTC 2017
Hi Mandy,
On 5/10/2017 4:12 AM, mandy chung wrote:
> This patch separates the JNI `FindClass` issue from the review thread
> for JDK-8188052 [1] into a different issue.
>
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html
src/hotspot/share/prims/jni.cpp
Okay ... so by nulling fromClass in the classloader during finalization
(soon to be moved to the Cleaner) you can now distinguish between the
OnLoad case and the OnUnload case, within FindClass - a comment to
clarify that would be good, please.
However you still have:
407 if (loader.is_null() &&
but you deleted the initialization of loader:
- 404 loader = Handle(THREAD, k->class_loader());
so it will by default be null. I suppose checking the loader is only a
potential optimization as the name of the class will be uniquely
determined anyway. But the code should be cleaned up.
---
Otherwise all seems fine.
Thanks,
David
>
> This patch changes `FindClass` to specify the class loading context used
> for the load and unload hook. `FindClass` when called from JNI_OnUnload
> is changed to use the system class loader as the context. This is an
> incompatible behavioral change and this bumps the version so that a
> native library can determine the new behavior if desire. This change
> proposes to defines JNI_VERSION_10 and I expect this name will be
> revisited along with the version string for the proposed new release
> cadence [2].
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8188069
>
> Thanks David for the suggested spec wordings.
>
> thanks
> Mandy
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049292.html
>
> [2]
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
More information about the hotspot-runtime-dev
mailing list