JDK-8190312 : javadoc -link doesn't work with http: -> https: URL redirects
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-27
  • Updated: 2018-12-05
  • Resolved: 2018-11-26
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 12
12 b22Fixed
Related Reports
Relates :  
Relates :  
It seems like everybody is moving from http to https as the preferred protocol (good!) BUT:

If I use javadoc -link with http: URLs the output for e.g. java.util.List in """All Implemented Interfaces""" is NOT linkified, whereas with https: it works fine.

I notice today that attempting to visit
is "autocorrected" (redirected?) to use https instead
which might possibly be related.


 $ (for file in JavadocLinkBug.java Makefile; do cat $file; echo ---; done; make clean 9; /usr/bin/google-chrome --incognito --user-data-dir=/tmp/chrome-view-url.gtWVr7Vd7Z --allow-file-access --allow-file-access-from-files --no-first-run file://${PWD}/JavadocLinkBug.html)
public abstract class JavadocLinkBug implements java.util.List {}
JDK9 = ~/jdk/jdk9
JDK10 = ~/jdk/jdk10

	$(JDK9)/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
	$(JDK10)/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
	$(JDK9)/bin/ javadoc -link https://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
	$(JDK10)/bin/javadoc -link https://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java

	rm -rf *.html *.js *.css *.zip resources/ jquery/ package-list

.PHONY: 9 10 9-https 10-https clean
rm -rf *.html *.js *.css *.zip resources/ jquery/ package-list
~/jdk/jdk9/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
Loading source file JavadocLinkBug.java...
Constructing Javadoc information...
Standard Doclet version 9.0.1
Building tree for all the packages and classes...
As noted above, URLConnection will not follow redirects, and not across protocol changes, like http: to https:. HttpClient will do that but that adds a new module dependency. It's easier to handle the redirects using URLConnection.

Maybe we can use the new HttpClient API which follows redirects.

If it does not already do so, javadoc should detect/report any connection issues with the given URL, and should maybe try and give "friendly" messages for common cases of failures.

Any affected user can usually fix their own problem by switching from http: to https: and we did that in the jsr166 project. But many users will be affected without understanding the problem, and their javadoc links will silently stop working.

We conjecture that the package-list handling in jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java needs to handle redirects, or at least redirects between http: and https: private void readPackageListFromURL(String urlpath, URL pkglisturlpath) throws Fault { try { URL link = pkglisturlpath.toURI().resolve(DocPaths.PACKAGE_LIST.getPath()).toURL(); readPackageList(link.openStream(), urlpath, false);

We conjecture that the failure is due to URLConnection not following redirects, as was decided long ago. Perhaps javadoc has the responsibility of following redirects?

URLConnection does not follow redirects. ###@###.### 2002-01-29 After discussion among Java Networking engineers, it is felt that we shouldn't automatically follow redirect from one protocol to another, for instance, from http to https and vise versa, doing so may have serious security consequences. Thus the fix is to return the server responses for redirect. Check response code and Location header field value for redirect information. It's the application's responsibility to follow the redirect. ###@###.### 2002-04-12