RFR: 8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString [v7]

[Mandy Chung]

On Thu, 22 Jun 2023 01:38:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed recommendations from Alan

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1229:

> 1227:      * Note that this is not a strict inverse of {@link #fromMethodDescriptorString fromMethodDescriptorString}.
> 1228:      * Two distinct classes which share a common name but have different class loaders
> 1229:      * will appear identical when viewed within descriptor strings.

Re-reading this, I think this api note reads fine.   OTOH I find a little confusing how you rephrased it.  "A method type produced by changing a component class object to...".   I understand you tried to make it crystal clear two method types may have the identical descriptor strings even if its parameter type or return type are distinct Class objects.   

I think the original version is clear enough and less lengthy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242627816