JDK-8172672 : Unsafe.defineAnonymousClass should not require non-null host class argument
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2017-01-11
  • Updated: 2020-03-17
  • Resolved: 2019-07-23
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 14
14Resolved
Related Reports
Duplicate :  
Relates :  
Description
Currently Unsafe.defineAnonymousClass requires its host-class argument to be non-null.  This requirement should be relaxed, so that anonymous classes can be injected into packages without *also* injecting them into the nest of a host class.

The nest-injection behavior is inappropriate when using anonymous classes for proxies.

Also, the nest-injection behavior needs to be made optional if anonymous classes are going to be loaded by untrusted code, via a Lookup API.  The logic of Lookup.defineAnonymousClass is such that if the Lookup object does *not* have PRIVATE level access, it *must not* inject the anonymous class code into any other class's nest.

In order to properly specify the class loader and protection domain for a non-hosted anonymous class, the API will have to provide these values.  Perhaps the best way to accomplish this is to add a new overloading (and/or flag) to Unsafe.defineAnonymousClass which uses a class argument as a "weak host", providing no nest-mate access, but only the appropriate loading context.

Unsafe.defineAnonyousClass(Class<?> hostClass, boolean addToNest, byte[] data, Object[] cpPatches)

(Until now, the workaround for the bug has been to pick a "random victim" as a host class.  This is perhaps appropriate for privileged users of Unsafe, but will not work for less-privileged users such as proxy generators.)
Comments
Current POR is to deprecate/remove unsafe.defineAnonymousClass and migrate to lookup.defineClass which will not have a host klass concept. Goal is to migrate to use nest mates for the lookup.defineClass with private access, so this is an extension of the nest mates work. There is also a goal of decoupling access controls from the concept of whether a class is findable via Class.forName(), findClass() etc.
04-04-2017