On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <li...@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. Class::getName was a partial inverse instead. >> 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 classloaders. >> >> 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/04/java.base/java/lang/Class.html >> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html > > Chen Liang has updated the pull request incrementally with one additional > commit since the last revision: > > Update the note for getName For `Class::getName`, I think #14528 should clarify it. For `MethodType`, I suggest the following: --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java @@ -1161,28 +1161,29 @@ class MethodType } /** - * Finds or creates an instance of a method type, given the spelling of its bytecode descriptor. - * Convenience method for {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}. + * Finds or creates an instance of a method type of the given method descriptor + * (JVMS {@jvms 4.3.3}). This method is a convenience method for + * {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}. * Any class or interface name embedded in the descriptor string will be - * resolved by the given loader (or if it is null, on the system class loader). + * resolved by the given loader (or if it is {@code null}, on the system class loader). * * @apiNote * It is possible to encounter method types which cannot be * constructed by this method, because their component types are - * not all reachable from a common class loader, or some component types - * cannot be {@linkplain ##descriptor described nominally}. + * not visible from a common class loader. * <p> * This method is included for the benefit of applications that must * generate bytecodes that process method handles and {@code invokedynamic}. * @param descriptor a bytecode-level type descriptor string "(T...)T" * @param loader the class loader in which to look up the types * @return a method type matching the bytecode-level type descriptor - * @throws NullPointerException if the string is null - * @throws IllegalArgumentException if the string is not well-formed + * @throws NullPointerException if the string is {@code null} + * @throws IllegalArgumentException if the string is not a method descriptor * @throws TypeNotPresentException if a named type cannot be found * @throws SecurityException if the security manager is present and * {@code loader} is {@code null} and the caller does not have the * {@link RuntimePermission}{@code ("getClassLoader")} + * @jvms 4.3.3 Method Descriptors */ public static MethodType fromMethodDescriptorString(String descriptor, ClassLoader loader) throws IllegalArgumentException, TypeNotPresentException @@ -1230,7 +1231,7 @@ class MethodType * 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. + * have the identical descriptor strings. * <p> * This method is included for the benefit of applications that must * generate bytecodes that process method handles and {@code invokedynamic}. With these clarification, would you think it's clearer? CNFE or IAE is thrown for the negative cases and no need to mention in API note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1595250196