On Wed, 14 Jun 2023 01:26:25 GMT, Chen Liang <[email protected]> wrote:
>> This method was added prior to `MethodTypeDesc`.
>> MethodTypeDesc::ofDescriptor` and `MethodTypeDesc::resolveConstantDesc`
>> would be the alternative way to get back the method type. I tend to think
>> that `descriptorString` would not need that distinct class loader note (as
>> it would use the Lookup class to resolve instead).
>
> Since the method type descriptor info is available in `descriptorString` but
> it's a reason `toMethodDescriptorString` is not a strict inverse of
> `fromMethodDescriptorString`, I propose to reword the notes sections to the
> following:
>
> * @apiNote
> * This is not a strict inverse of {@link #fromMethodDescriptorString
> * fromMethodDescriptorString} which requires a method type descriptor
> * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
> * classes which share a common name but have different class loaders will
> * appear identical when viewed within descriptor strings.
> * <p>
> * This method is included for the benefit of applications that must
> * generate bytecodes that process method handles and {@code
> invokedynamic}.
That's good.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228884412
