JDK-8209676 : Dynamic nestmate injection in the VM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-08-20
  • Updated: 2020-02-27
  • Resolved: 2020-02-27
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8238358 - Implementation of JEP 371: Hidden Classes
Relates :  
JDK-8171335 - MethodHandle.Lookup functionality to define a nestmate class
Description
The proposed Lookup.defineClass API (JDK-8171335) as well as future language enhancements ( e.g. "generic specialization") require the ability to dynamically inject a class into an existing nest.

This issue tracks the JVM side of this capability.
Comments
This will be integrated using the main JEP implementation issue - JDK-8238358
27-02-2020
The Lookup API injects a nestmate class into a nest of the lookup class which may or may not be the nest host. No nested nest created. In the current prototype, the library passes the lookup class to VM that will find the nest host of the lookup class first and then define the nestmate class in the nest of the lookup class. Alternatively, the library can pass the nest host to the VM by calling `Class::getNestHost0` or avoid a VM call, it could cache the nest host in `Class` object.
12-07-2019
With static nestmates the NestHost attribute is used to indicate a class belongs in a specific nest. If an access control check needs to determine nestmate access then the CP index for the NestHost attribute is resolved, the purported nest host is examined to see if the current class is listed as a nest member, and if so the _nest_host field is updated with the resolved nest-host class. The nest host class is loaded if needed. For dynamic nest injection, as prototyped for JDK-8171335, we expect to be given the nest-host instanceKlass into which the current class is to be injected. This means that no classloading is involved. We can simply set the _nest_host field directly and therefore by-pass the nest membership validation check based on the NestMembers attribute. As a sanity check I propose that when setting the nest-host this way we also verify that the current class does not have a NestHost attribute value set. If it does than an exception should be thrown - ClassFormatError might be appropriate. As discussed in the context of JDK-8171335 there are questions as to what the core reflection nest API should do when dealing with a dynamically injected nest member. For getNestHost() it seems reasonable to return the nest-host for the nest the class was injected into. This will happen for free as we just return the _nest_host field. It remains debatable whether getNestMembers() should be extended to return dynamic nestmates along with static ones - to some extent it depends on the form of injection used. For example, the equivalent of a VM anonymous class today, would reasonably be expected to be invisible; however for generic specialization (if implemented using nests - this is all hypothetical for now) it might be reasonable for getNestMembers() to return all the existing specializations. I don't think we need to answer that question before this enhancement is implemented, indeed it may be best to address it on a use-case by use-case basis.
20-08-2018