4

I am using javadoc to document my public enum. I am compiling all of my following examples using the following command:

javac   -Xdoclint:all     LetsLearnJavadocXdoclint.java

If my enum is like this, it generates a .class file without any warnings.

/** Comment LetsLearnJavadocXdoclint. */
public enum LetsLearnJavadocXdoclint
{
   /** Comment A. */A;
}

But if my enum is like this:

/** Comment LetsLearnJavadocXdoclint. */
public enum LetsLearnJavadocXdoclint
{
   /** Comment A. */A{};
}

.....I get the following error.....

LetsLearnJavadocXdoclint.java:4: warning: no comment
   /** Comment A. */A{};
                    ^
1 warning

Thinking I needed to put the comment somewhere else, I decided to put a comment into every possible position.....

/** Comment LetsLearnJavadocXdoclint. */
public enum LetsLearnJavadocXdoclint
{
   /** Comment A. */A/** Comment A. */{/** Comment A. */}/** Comment A. */;
}

.....to no avail.....

LetsLearnJavadocXdoclint.java:4: warning: no comment
   /** Comment A. */A/** Comment A. */{/** Comment A. */}/** Comment A. */;
                    ^
1 warning

And to be absolutely, positively certain, I went to the logical extreme.

/** At this. */
public
/** point, I. */
enum
/** am beginning. */
LetsLearnJavadocXdoclint
/** to think. */
{
/** that I. */
   A
   /** am not. */
   {
   /** the one. */
   }
/** who is. */
   ,
/** at fault. */
   ;
/** here. */
}
/** Next question. How do I report a bug to Java? */

.....and still got.....

$ javac -Xdoclint:all LetsLearnJavadocXdoclint.java
LetsLearnJavadocXdoclint.java:10: warning: no comment
   A
   ^
1 warning

Am I missing something?

And to explain my intent a little better, my actual goal is to have this enum implement an interface with a single method, and then have every enum value within my enum provide their own unique implementation of the method. I have been trying to document it using javadoc, but to no avail. And that is how I came up with this minimal example.

If I had to guess, it probably has something to do with anonymous classes. I think those curly braces I included are creating some form of anonymous class, and it is trying to comment both the anonymous class AND the enum value. I guessed this because of the following example.

If I attempt to do this.....

/** Comment LetsLearnJavadocXdoclint. */
public enum LetsLearnJavadocXdoclint
{
   A{};
}

.....I get this.....

LetsLearnJavadocXdoclint.java:4: warning: no comment
   A{};
   ^
LetsLearnJavadocXdoclint.java:4: warning: no comment
   A{};
   ^
2 warnings

2 warnings

.....which immediately makes me think anonymous classes.

Obviously, I don't know for sure, but why else would it have 2 WARNINGS unless it was because there was the enum class, and the anonymous class that it was expecting documentation from?

Finally, here is my information.

$ javac -version
javac 1.8.0_281

$ java -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)
davidalayachew
  • 1,279
  • 1
  • 11
  • 22
  • Also, could someone with more reputation than me (>1500) add a Xdoclint tag to this question? I feel that that may help others in a similar situation as me find the answer to their question faster. – davidalayachew Apr 08 '21 at 19:53
  • 1
    Not really enough things match `[javadoc] xdoclint` in a search for it to be worth making a tag. Plain `javadoc` is good enough as a tag for now. – Donal Fellows Nov 15 '22 at 15:50

1 Answers1

4

The optional class body of an enum constant implicitly defines an anonymous class declaration (see the Java Language Specification). The Javadoc tool does not directly document anonymous classes -- that is, their declarations and doc comments are ignored. The following example of an anonymous class produces the same two warnings:

public class MyClass {

  private Runnable cleanUpOperation = new Runnable() {

    @Override
    public void run() {

    }
  };

}

One warning for the missing comment of the cleanUpOperation field and one for the missing comment of the anonymous sub class of Runnable. There is no way to add a comment to an anonymous class. Oracle suggests to document an anonymous class in the doc comment of its outer class or any other closely related class (for details see here). So in your case this would be the doc comment of your enum class or the enum constant.

-Xdoclint:all shows a warning for missing javadoc comments for public, protected, package and private members. This includes also anonymous classes.

To get rid of your warnings you could tell doclint to ignore missing comments for private members with -Xdoclint:all,-missing/private. Execute javac -X for help on how to configure doclint for your purposes.

rmunge
  • 3,653
  • 5
  • 19
  • 2
    If there is no way to add a comment on an anonymous class then the tool should not complain about it, no? – M A Apr 12 '21 at 14:41
  • Thank you for the answer, it's well supported and well researched. I also found new places to look up documentation, so thank you for that (I've only ever known of the basic documentation - https://docs.oracle.com/javase/7/docs/api/java/awt/GridBagLayout.html or the tutorials - https://docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html). I guess my final question is - would this count as a bug/defect of javadoc? – davidalayachew Apr 12 '21 at 15:55
  • Just did some testing on this myself - while I think this solution is the best I'm going to get, I don't like it because it means that private instance variables without a comment will not trigger a warning. I'll accept this as the answer for now, but I'll hold off on awarding the bounty in hopes that a better solution comes along. – davidalayachew Apr 13 '21 at 01:24
  • 2
    @MA I have just submitted a bug to Oracle/Java for this. If anyone wants to follow along, here is the defect number (9069884). You can follow along by plugging that number here - https://bugs.java.com/bugdatabase/index.jsp It's not currently available now, but it should be whenever the system generates the bug report. If anything changes, I will delete this comment and update here. – davidalayachew Apr 13 '21 at 01:25
  • 1
    @MA Here is the new bug number - JDK-8265253, but it looks like they immediately said it is not an issue :( I am going to contest it though, and see if I can get them to change their minds. – davidalayachew Apr 15 '21 at 19:38
  • 1
    @MA They are reconsidering! https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8265253 They have not accepted it as a bug they need to fix yet though, so I am still fighting. But this is progress! – davidalayachew Apr 17 '21 at 01:12
  • @MA They now agree that it is an issue! https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8265253 It is not yet been fixed, but they acknowledge it! That is progress! – davidalayachew May 04 '21 at 03:00
  • 1
    @davidalayachew Good to know that! – M A May 04 '21 at 07:24
  • 2
    @MA They have accepted it as an issue and committed a fix! We have helped improve Java! Thank you and rmunge for helping to make this possible! https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8265253 – davidalayachew Aug 28 '21 at 21:17
  • I wish I knew how to test the fix myself though. I think I have to wait for Java 18 to come out? – davidalayachew Aug 28 '21 at 21:17
  • Just tested the fix using this build (https://jdk.java.net/18/) - it works exactly as expected! All uncommented fields/methods in the anonymous class body still throw warnings, but the uncommentable anonymous class no longer throws an error! And of course, it still checks the enum value itself (A in my example) for a top level comment, so this is a very neat and elegant fix by Jonathan Gibbons. Thank you all again! – davidalayachew Oct 02 '21 at 10:51