JDK-8340963 : Make some ClassDesc methods no longer default
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Finalized
  • Resolution: Unresolved
  • Fix Versions: 24
  • Submitted: 2024-09-25
  • Updated: 2024-10-22
Related Reports
CSR :  
Description
Summary
-------

Mark some ClassDesc methods, whose implementations are now specialized into subclasses in the sealed hierarchy, as abstract.

Problem
-------

ClassDesc is getting specific implementations; some previous default implementations are better converted to non-concrete abstract methods and be overridden in implementations instead.

The specification of `displayName` is too restrictive; there are other human-readable options for class or interface names such as package abbreviations, but the current spec of `displayName` forbids such implementations.

Solution
--------

Make these methods in `ClassDesc` abstract (non-default):

 - `arrayType()`
 - `arrayType(int)`
 - `displayName()`

Relax the implementation specification on `displayName()`.

Specification
-------------

```
-    default ClassDesc arrayType() {
+    ClassDesc arrayType() {
-    default ClassDesc arrayType(int rank) {
+    ClassDesc arrayType(int rank) {
-     * Returns a human-readable name for the type described by this descriptor.
-     *
-     * @implSpec
-     * <p>The default implementation returns the simple name
-     * (e.g., {@code int}) for primitive types, the unqualified class name
-     * for class or interface types, or the display name of the component type
-     * suffixed with the appropriate number of {@code []} pairs for array types.
-     *
-     * @return the human-readable name
+     * {@return a human-readable name for this {@code ClassDesc}}
      */
-    default String displayName() {
+    String displayName() {
```

Comments
I have decided to relax the specification for `displayName`: other implementations, including the reference implementation in the future, should be free to use the binary name for classes or interfaces for a display name, or abbreviations like `ja.ut.List` or `j.u.List` for `java.util.List`. Another reason is that `MethodTypeDesc::displayName` incorrectly calls these display names as "canonical names," which is false for some classes or interfaces.
22-10-2024

Moving to Provisional, not Approved. [~liach], for the implSpec issue, in this case I recommend promoting the implSpec text to normal spec text. For example, leading to something like: Returns a human-readable name for the type described by this descriptor. For primitive types, ... For class or interfaces types, ... For array types, ... otherwise, this change looks fine.
18-10-2024

[~darcy] In particular, I wonder what happens to `@implSpec` tags for non-default methods: I do not immediately recall if we have any `@implSpec` tag on non-default methods in the JDK. If we make such a method abstract, should we convert this to part of API specification or API note?
08-10-2024

Moving to Provisional.
01-10-2024

Propose for a round of review: [~redestad] disagrees with my wording of "abstract" and suggest to use "remove default modifier" instead. I kept some occurrences of "abstract" for the default modifier removal, as interface non-private non-static methods are implicitly abstract unless marked default.
30-09-2024