JDK-8071851 : Provide filtering of doclint checking based on packages
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-29
  • Updated: 2017-05-17
  • Resolved: 2015-03-11
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.
JDK 9
9 b55Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
As part of clearing doclint warnings from the JDK code base (JDK-8071630), it has been observed that neither the doclint checking that could be done by javac during a JDK build nor the doclint checking that could be done by javadoc during a docs build aligns well with the portions of the JDK code base that have been cleared of javadoc warnings.

Attempting to use doclint with javac would require fixing thousands of warnings in the sun.*, com.sun.*, and jdk.internal.* packages for which javadoc is not generated.

Attempting to use doclint with javadoc would require fixing thousands of warnings in the corba, jaxp, and jaxws repositories, which is a noble goal, but not one likely to be achieved any time soon.

Despite this, most of the packages in the jdk Hg repository for which documentation is generated are clear or nearly clear of doclint warnings. However, they are at constant risk of doclint regressions being introduced since there is no on-going programmatic enforcement of doclint checks.

If doclint checking could be enabled in javac for only for type meeting a package name filter, that would allow enforcement of a useful and practical doclint policy. (Filtering on modules instead of packages would be too coarse since not all types in a module are exported or have javadoc generated for them.)
Comments
After discussions with Joe, the preference is something like 2a or 2b, meaning a new sub option that is orthogonal to the existing options. Thus, the existing option says "what checks to apply": -Xdoclint:(all|none|[-]<group>)[/<access>] The new option would specify "what files to apply the check to". If no packages (or modules, in time?) are specified, the default is "all". Otherwise, the checks are applied to any file within the given set(s) of packages or modules. We might want to (separately?) make the same available for javadoc, and generally align the javadoc options with the javac ones, but that is lower priority and could be done separately.
05-02-2015

I could see the following as nice: javac .... args .... -Xdoclint:all/protected -Xdoclint/package:java.*,javax.* or a variant like javac ... args ... @$(DOCLINTOPTS)
29-01-2015

For reference, here is the existing option: -Xdoclint Enable recommended checks for problems in javadoc comments -Xdoclint:(all|none|[-]<group>)[/<access>] Enable or disable specific checks for problems in javadoc comments, where <group> is one of accessibility, html, missing, reference, or syntax, and <access> is one of public, protected, package, or private. Also for consideration, here is the existing javadoc option: -Xdoclint Enable recommended checks for problems in javadoc comments -Xdoclint:(all|none|[-]<group>) Enable or disable specific checks for problems in javadoc comments, where <group> is one of accessibility, html, missing, reference, or syntax. although I would like to see the javadoc option be aligned with the javac one. Suggestion 1a: Add a new /<package> qualifier, as in: -Xdoclint:(all|none|[-]<group>)[/<access>]/<package> Suggestion 1b: Add a new /<package> qualifier, as in: -Xdoclint/<package>:(all|none|[-]<group>)[/<access>] Suggestion 2a: A new option, orthogonal to existing option: -Xdoclint/module:<module> -Xdoclint/package:<package> Suggestion 2b: A new option, orthogonal to existing option: -Xdoclint/module:<module-regex> -Xdoclint/package:<package-regex> Suggestions 1a, 1b allow very specific control on individual packages (and modules?) Suggestions 2a, 2b provide broader control, by treating filtering separately from the checks being applied Note that extended lists of options (e.g. for lists of packages) can be handled with @-files. Suggestion 3, for completeness: new doclint tool with its own full easier-to-use set of options
29-01-2015