Bug ID: JDK-8243287 Removal of Unsafe::defineAnonymousClass

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17
17 b23Fixed

Changeset: e14b0268 Author: Harold Seigel <hseigel@openjdk.org> Date: 2021-05-13 12:46:54 +0000 URL: https://git.openjdk.java.net/jdk/commit/e14b0268411bba8eb01bf6c477cc8743a53ffd1c

13-05-2021

I'm fine with the removal, although I want to mention that Nashorn uses this facility too[0], and when I tried to replace it with the hidden classes facility the issue we run into was that hidden classes' methods didn't show up in stack traces the way anonymous classes' methods did[1]. Since Nashorn uses anonymous classes to install compiled JavaScript application code, it is important to be able to report stack traces from them. It unfortunately can't just use StackWalker, as it has to post-edit traces of already thrown exceptions. So ensuring JDK-8212620 is implemented as well, and/or maybe having a `MethodHandles.Lookup.ClassOption` to specify the class should show up in stack traces would be important to implement alongside the removal. It's not a show-stopper, Nashorn will be able to gracefully fail over to ordinary class loading in absence of anonymous class loading, but I'd really like to be able to transition to using hidden classes if we could get them to show up in stack traces. [0] https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L329 [1] https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007578.html

11-05-2021

There are many regression tests added for `Unsafe::defineAnonymousClass`. We should convert the regression tests for `Unsafe::defineAnonymousClass` to use `Lookup::defineHiddenClass` where appropriate or unless the same test exists for hidden class [1]. [1] http://hg.openjdk.java.net/valhalla/valhalla/rev/3ff43480c2a2

28-04-2021

CSR :	JDK-8266760 - Remove sun.misc.Unsafe::defineAnonymousClass
Relates :	JDK-8267338 - [JVMCI] revive JVMCI API removed by JDK-8243287
Relates :	JDK-8220607 - JEP 371: Hidden Classes
Relates :	JDK-8269602 - Gracefully handle absence of Unsafe.defineAnonymousClass
Relates :	JDK-8205939 - JVM support to replace Unsafe.defineAnonymousClass
Relates :	JDK-8266925 - Add a test to verify that hidden class's members are not statically invocable
Relates :	JDK-8272107 - Removal of Unsafe::defineAnonymousClass left a dangling C++ class
Relates :	JDK-8265694 - Investigate test StressHiddenClasses.java
Relates :	JDK-8069233 - JSR 292: reject redefinitions if patched string becomes non-patched and vice versa
Relates :	CODETOOLS-7902718 - JDK-8247444 protections for Record offsets break JOL introspection
Relates :	JDK-8212620 - Provide a mechanism to allow a class/method to request filtering from the stack trace
Relates :	JDK-8230501 - Class data support for hidden classes
Relates :	JDK-8235521 - Replacement API for Unsafe::ensureClassInitialized
Relates :	JDK-8171335 - MethodHandle.Lookup functionality to define a nestmate class
Relates :	JDK-8296262 - Remove dead code from InstanceKlass::signature_name()

JDK-8267178 :	Release Note: Removal of sun.misc.Unsafe::defineAnonymousClass - Closed
JDK-8267179 :	Add a release note for removing Unsafe.defineAnonymousClass - Closed