JDK-8230502 : Add support in JVM TI, JDI, and Instrumentation for hidden classes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Priority: P2
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2019-09-03
  • Updated: 2020-05-12
  • Resolved: 2020-05-01
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
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8241214 :  
JDK-8241807 :  
JDK-8242237 :  
Description
From JVM's point of view, a hidden class is a normal class except the following:

   1. A hidden class has no initiating class loader and is not registered in any dictionary.
   2. A hidden class has a name containing an illegal character
      `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` returns "Lp/Foo.0x1234;".
   3. A hidden class is not modifiable, i.e. cannot be redefined or retransformed.
      JVM TI (IsModifableClass)[https://download.java.net/java/early_access/jdk15/docs/specs/jvmti.html#IsModifiableClass] returns false on a hidden class and VM anonymous class.

VM anonymous class vs Hidden class

   - VM anonymous class is not registered in any dictionary and is also not modifiable.
   - There is no specification for VM anonymous class and hence never specified
     it has or does not have an initiating loader.
   - GetClassSignature returns "Lp/Foo/0x1234;" on a VM anonymous class with no illegal character
     whereas GetClassSignature returns "Lp/Foo.0x1234;" for a hidden class.
     VM anonymous class might be incorrectly interpreted as a normal class and
     `p.Foo` as the package name.

The proposal is that hidden classes are deemed as "loaded" classes, i.e. essentially all derived classes.  Hidden classes are not "treated" specially.
Comments
Reclosing as "Delivered" since all changes were pushed via subtasks.
01-05-2020

Only issues associated with changesets should be closed as "Fixed". Reopening.
01-05-2020

The fix of this enhancement consists of fixes of its 3 sub-tasks. The Serviceability spec clarifications were integrated the enhancement JDK-8238358.
29-04-2020

> Comment from John. R.: > I think I���ve made my point clearly. What do other folks think? This point from John R. sounds right to me.
23-03-2020

The following needs investigation 1. GetClassLoaderClasses Should GetClassLoaderClasses be updated to return hidden classes? Note that no initiating class loader is recorded in a hidden class but it has a defining class loader. Relevant APIs should be investigated as well: java.lang.instrument.Instrumentation::getInitiatedClasses JDI ClassLoaderReference::definedClasses and visibleClasses I think this function should include the hidden classes defined by the given loader and the spec should be updated to reflect that. 2. GetClassSignature A hidden class should not appear in a field or method signature. The name returned by GetClassSignature on a hidden class is incorrect. For a hidden class, its name contains "/". So the internal form of "com.example.Foo/1234" is "com/example/Foo/1234". Maybe this returns an error if this is called on a hidden class. 3. GetSourceFileName Mostly testing. If a hidden class has the SourceFile attribute, this should return the correct value but its source file name won't match the hidden class' name. 4. source-level debugging It should work for hidden classes while the debugger implementation may not handle that. 5. Any need to add JVM TI IsHiddenClass? Or calling `Class::isHidden` is adequate? 6. The spec of com.sun.jdi.ReferenceType::name should probably need update.
10-12-2019