Annotation to disable JavaDocs

Question

Is there an annotation to declare that a certain method will not be included in the JavaDocs even though it is public?

Something like:

@nojavadocs
p         


        

Answer 1

/**
 *  Don't use this method <br>
 *  <i>or all your data will be lost.</i>
 */
public void foo(){
    //...
}

well, use a better explanation why the user should not use this method...
Remember that it's not hard to find any (public) method using a decompiler or Reflection.

Answer 2

Not if you're using Sun's JavaDocs tool.

They have a feature request for it, but it's been in low priority since 1997.

You can write a custom doclet to overcome this, or use a 3rd-party tool (DocFlex or such).

Answer 3

Yes...but not in a good way (having methods that are public that aren't really "public" isn't a great design practice).

You could follow the suggestion given in this thread and mark the method using @deprecated then when you run javadoc use option -nodeprecated.

Edit: As others have noted, this is not a desirable course of action. This will solve your problem, but you really need to rethink why it is you want to hide the method -- given a compiled version of your code someone will still be able to see your function; hiding it in the documentation does not in fact hide the method. I really mean to stress here that the qualifiers private, public and protected have meaning which you should consider and utilize effectively. There is no such thing as a "hidden" public method.

Answer 4

The only reason I could think of that you'd want to do this would be to "hide" the method in some sense, if only in terms of documentation. If you did that you'd be designing the documentation to be "broken" in the sense that documentation becomes broken when it goes out of date and no longer accurately reflects what the class does. Since the method is still part of the public API you're not really hiding it anyway.

If you want a method to be unused outside of the class or a few users, make it private, or package. If this is inconvenient and it must be public, I'd just document very clearly the limitations on its use, possibly with a naming convention (for example, python does this, there are entity names surrounded by underscores, that you can see but are meant to be more part of the class implementation than the public api)