Review Request: 8238358: Implementation of JEP 371: Hidden Classes
Chris Plummer
chris.plummer at oracle.com
Mon Apr 20 20:06:07 UTC 2020
On 4/18/20 3:28 PM, Mandy Chung wrote:
> Hi Chris, Serguei,
>
> On 4/18/20 12:18 AM, Chris Plummer wrote:
>>
>> Yes. I'd like to see all this as part of the Class/Classloading spec
>> in some sort of section that gives an overview of all these topics,
>> but mostly clarifies what an initiating loader is, and the (non)
>> relationship to hidden classes.
>
> We should refer initiating loader and class loading from JVMS 5.3.
> JVM TI needs the clarification w.r.t. GetClassLoaderClasses that does
> not include hidden classes because the initiating class loader cannot
> find it.
>
> GetLoadedClasses is about class creation. While it seems tempted to
> put the descriptions in some sort of overview section, I found the
> clarification is specific for each function and hence inlining them in
> each function helps the readers directly see the difference.
>
> I made a few changes that should ease your concern of duplication:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/
>
> - The class creation description added in GetLoadedClasses. Not in
> JDWP, JDI and Instrumentation.
> - The description in GetClassLoaderClasses,
> Instrumentation::getInitiatedClasses,
> ClassLoaderReference::visibleClasses is revised to take out the
> details. Add links from JDWP and JDI to GetClassLoaderClasses.
> - The details about hidden classes can be found from `Class::isHidden`
> and `Lookup::defineHiddenClass`.
>
> Mandy
Hi Mandy,
This looks much better. Thank you for the consolidating and the cross
references. I think that's a big improvement.
One minor thing I noticed is a few "JNI-style signature" references. In
LocalVariable.java you renamed "JNI signature" to "JNI-style signature",
but in JDI Mirror.java you renamed "JNI-style signature" to "type
signature". And then in JDI TypeComponent.java you left the "JNI-style
signature" reference unchanged. Why the inconsistency?
In VirtualMachine.java:
145 * @see Class or interface creation specified in
146 * <a
href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI
GetLoadedClasses</a>
How about:
145 * @a description of how Class and interface creation can be
triggered is specified in
146 * <a
href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI
GetLoadedClasses</a>
I read the following incorrectly a few times before I finally understood
the meaning:
44 /**
45 * Returns the {@linkplain com.sun.jdi.Type#name() name of the
class}
46 * that has been unloaded. The returned string may not be a
47 * <a
href="${docRoot}/java.base/java/lang/ClassLoader.html#binary-name">binary
name</a>.
48 *
49 * @see Class#getName()
50 */
51 public String className();
52
53 /**
54 * Returns the {@linkplain com.sun.jdi.Type#signature() type
signature of the class}
55 * that has been unloaded. The returned string may not be a
type descriptor
56 * specified in JVMS {@jvms 4.3.2}.
57 *
58 * @see java.lang.invoke.TypeDescriptor#descriptorString()
59 */
60 public String classSignature();
"may not be" through me off. I read it as "is not allowed not be". Your
intent was "might not be", which might be a better choice of words.
thanks,
Chris
More information about the serviceability-dev
mailing list