-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
b19
It has long been understood that correct use of javac and javadoc `-source` option should be accompanied by an equivalent `-bootclasspath` option ... and equally understood that this is often-times difficult in a development environment, since it requires access to an installed version of the relevant API. This led to the introduction of the `--release` option for both java and javadoc, such that the compilation environment automatically provides access to the appropriate version of the platform classes.
There is a similar issue in javadoc with respect to linking to the API docs for the platform classes. The issue is not as severe (or as well known) as the `-bootclasspath` problem, because it is often common practice to not link to the platform API docs at all, but for those that do want to link to the platform API docs, it is similarly tedious. Either one must have access to the Internet, to use the `-link` option, or one must have access to a local version of the API description file (originally packages.list, now element.list) for the appropriate API. If one uses the `link` option to access the API description file via the Internet, one must deal with the irregularities in the URLs for the API docs for different releases. See, for example, this code in the Maven javadoc plugin, that has to maintain a mapping table:
https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L1761
It would be better if javadoc itself knew the mapping table, and/or provided local copies of the API description files, so that clients did not have to ... whether the clients are running javadoc directly, or via a plugin for a build system like Ant or Maven.
Note ... it should still be possible for a user to override the default location, in the same way that a user can override the location of the compiled platform classes. Such overriding should presumably be done with the existing `-link` or `-linkoffline` options. This implies that javadoc should be able to examine the overall set of `-link*` options, to determine if any of the options provide a URL for the platform classes, such as by looking for a URL for the `java.lang` package. If no such URL is provided, then javadoc can provide a default.
It is arguably an open question whether it should be possible to disable this feature, so that platform classes are _not_ linked.
There is a similar issue in javadoc with respect to linking to the API docs for the platform classes. The issue is not as severe (or as well known) as the `-bootclasspath` problem, because it is often common practice to not link to the platform API docs at all, but for those that do want to link to the platform API docs, it is similarly tedious. Either one must have access to the Internet, to use the `-link` option, or one must have access to a local version of the API description file (originally packages.list, now element.list) for the appropriate API. If one uses the `link` option to access the API description file via the Internet, one must deal with the irregularities in the URLs for the API docs for different releases. See, for example, this code in the Maven javadoc plugin, that has to maintain a mapping table:
https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L1761
It would be better if javadoc itself knew the mapping table, and/or provided local copies of the API description files, so that clients did not have to ... whether the clients are running javadoc directly, or via a plugin for a build system like Ant or Maven.
Note ... it should still be possible for a user to override the default location, in the same way that a user can override the location of the compiled platform classes. Such overriding should presumably be done with the existing `-link` or `-linkoffline` options. This implies that javadoc should be able to examine the overall set of `-link*` options, to determine if any of the options provide a URL for the platform classes, such as by looking for a URL for the `java.lang` package. If no such URL is provided, then javadoc can provide a default.
It is arguably an open question whether it should be possible to disable this feature, so that platform classes are _not_ linked.
- csr for
-
JDK-8251181 New javadoc options for auto-link to platform classes
- Closed
- duplicates
-
JDK-8246346 javadoc --release should auto-link to JDK docs
- Closed
-
JDK-8232437 javadoc --release could auto-link to JDK docs
- Closed
- relates to
-
JDK-8212233 javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module."
- Resolved
-
JDK-8255801 Race when building ct.sym build tools
- Resolved
-
JDK-8253545 Add method to SourceVersion that returns the numeric version
- Closed
(1 relates to, 2 links to)