-
Enhancement
-
Resolution: Won't Fix
-
P4
-
6
-
generic, x86, sparc
-
generic, other, solaris_2.5.1, windows_95, windows_nt
This is a feature to enable developers to skip classes and packages when
running javadoc.
People might want gradations of exclusion --
they might want to exclude a class for expert developers (service providers),
but include it for normal developers. If the tag can be named, it would be
possible to include all classes with a certain name: "@exclude licensee"
would be excluded by default (with or without the name "licensee",
but could be overridden with "javadoc -include licensee".
This should work at the member level, class level and package level.
One developer suggests @publicAPI rather than @exclude. @publicAPI
would mark API that should be documented for external use (and in
his case, not be obfuscated). -public would be relegated to
internal documentation only. Reasons:
1) The methods, fields and classes that are API public are most
likely to have doc comments already, the @exclude would need
to be added to elements devoid of doc comments.
2) The API public elements are usually fewer in number than
the 'public' access symbols that would require '@exclude'
--------------------------------------------------------------
From another submitter:
One of the reasons we find it useful to exclude a class is that we have
a class in the package that can be used by support in the field but is
of no use to the programmer using the public api of the product in that
same package.
If we move this class to a sub package, it is now outside the package it wants
to be a part of for package private functionality.
running javadoc.
People might want gradations of exclusion --
they might want to exclude a class for expert developers (service providers),
but include it for normal developers. If the tag can be named, it would be
possible to include all classes with a certain name: "@exclude licensee"
would be excluded by default (with or without the name "licensee",
but could be overridden with "javadoc -include licensee".
This should work at the member level, class level and package level.
One developer suggests @publicAPI rather than @exclude. @publicAPI
would mark API that should be documented for external use (and in
his case, not be obfuscated). -public would be relegated to
internal documentation only. Reasons:
1) The methods, fields and classes that are API public are most
likely to have doc comments already, the @exclude would need
to be added to elements devoid of doc comments.
2) The API public elements are usually fewer in number than
the 'public' access symbols that would require '@exclude'
--------------------------------------------------------------
From another submitter:
One of the reasons we find it useful to exclude a class is that we have
a class in the package that can be used by support in the field but is
of no use to the programmer using the public api of the product in that
same package.
If we move this class to a sub package, it is now outside the package it wants
to be a part of for package private functionality.
- duplicates
-
JDK-4178490 Javadoc needs @hide tag
- Closed
-
JDK-4075128 Exclude/hide members of the Java source
- Closed