JDK-6287639 : Abstract methods in enum classes should not be listed as abstract
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2005-06-17
  • Updated: 2020-06-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-5035528 - JavaDoc for enum classes should omit final and abstract modifiers
Relates :  
JDK-5009943 - Javadoc generated for enums could be misleading
Description
One way to implement enum-constant specific behavior is to have the enum class declare an abstract method and then to have each specialized enum constant override the class (specialized enum constants are implemented as anonymous subclasses of the enum class).  Although the method is declared abstract in the enum, it is effectively not abstract since javac ensures that each enum constant provides a concrete implementation of the method.  Therefore, in this situation the generated javadoc should not list the "abstract" modifier on the method.

###@###.### 2005-06-17 23:29:29 GMT
Comments
Reading the above comments makes me inclined to agree with the request, subject to agreement by the JCK team. On the one hand I prefer listing "accurate" signatures, but I note as significant the comment that javadoc already hides some modifiers, like public abstract on interfaces.
01-03-2018
EVALUATION ###@###.###: This is an issue for the doclet. We should verify (perhaps Joe has given this more thought) that the "abstract" is truly not part of the specification, that it isn't checked by the JCK, etc. Doing this would be a bigger step than eliding optional "noise" keywords like the "public" on an interface member. It's closer in scope to what we do in StringBuffer and StringBuilder to hide all reference to the AbstractStringBuilder methods. ###@###.###: I asked Joe about this, and he's convinced me that it's the right thing to do. (pasted by Doug from email) ###@###.### 2005-07-19 17:20:44 GMT
19-07-2005