RFR: 8254979: Class.getSimpleName() returns non-empty for lambda and method
java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString(). Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s. Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case. ------------- Commit messages: - 8254979: Class.getSimpleName() returns non-empty for lambda and method Changes: https://git.openjdk.java.net/jdk/pull/3038/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3038&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254979 Stats: 10 lines in 1 file changed: 3 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3038.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3038/head:pull/3038 PR: https://git.openjdk.java.net/jdk/pull/3038
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy@openjdk.org> wrote:
java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.
Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3038
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy@openjdk.org> wrote:
java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.
Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3038
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy@openjdk.org> wrote:
java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.
This pull request has now been integrated. Changeset: 26234b53 Author: Joe Darcy <darcy@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/26234b53 Stats: 10 lines in 1 file changed: 3 ins; 1 del; 6 mod 8254979: Class.getSimpleName() returns non-empty for lambda and method Reviewed-by: rriggs, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/3038
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy@openjdk.org> wrote:
java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.
src/java.base/share/classes/java/lang/Class.java line 782:
780: 781: /** 782: *{@return {@code true} if and only if this class has the synthetic modifier
The braces around return tag are allowed? "{@return ...} vs. "@return ..." Seems inconsistent with other uses of return tags. ------------- PR: https://git.openjdk.java.net/jdk/pull/3038
Hello, On 3/17/2021 3:56 PM, jmehrens wrote:
On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy@openjdk.org> wrote:
[snip]
780: 781: /** 782: *{@return {@code true} if and only if this class has the synthetic modifier The braces around return tag are allowed? "{@return ...} vs. "@return ..." Seems inconsistent with other uses of return tags.
Yes; after a recently-added javadoc feature in JDK 16: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. https://bugs.openjdk.java.net/browse/JDK-8075778 The usage allow an explicit @return tag to be elided when it is the same as the first sentence of the javadoc. The docs in the java.compiler module have been updated to use the feature. HTH, -Joe
participants (5)
-
jmehrens
-
Joe Darcy
-
Joe Darcy
-
Mandy Chung
-
Roger Riggs