JDK-8216401 : Allow "file:" URLs in Class-Path of local JARs
  • Type: Bug
  • Component: core-libs
  • Affected Version: 7,8,11,13
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-01-09
  • Updated: 2020-02-18
  • Resolved: 2019-01-14
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 11 JDK 13 JDK 7 JDK 8 Other
11.0.5Fixed 13 b04Fixed 7u241Fixed 8u231Fixed openjdk8u242Fixed
Related Reports
Relates :  
Relates :  
Description
The JAR spec for the Class-Path[1] attribute states that entries must be relative URLs (though this wasn't enforced for much of Java's history).

It has come to light that there is software in the wild that is misusing the Class-Path, by including absolute "file:" URLs.

In the interest of compatibility, this long-standing behavior should be maintained.  We should allow "file:" entries in Class-Path for JARs loaded from the local disk.

Note that this change will not affect behavior by default, because the 
"jdk.net.URLClassPath.disableClassPathURLCheck" system property to disable Class-Path enforcement code is on by default.

1. https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute

Comments
This mail from Paul explains it: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010027.html The ClassFileInstaller.java test library file is duplicated between the HotSpot and JDK repositories. JDK-8189762 updated it in the HotSpot repository, but not the JDK repository. We need to sync them so the changes in this fix can be applied on top. The problem is avoided in later OpenJDK versions because there is only one copy of the test library under the unified repository structure. Fix now pushed: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ccb11b167ba0 so this can be backported.
17-12-2019

Hi, Severin. How does JDK-8189762 relate to backporting the present issue (JDK-8216401) to 8u? Does backporting JDK-8189762 block backporting the present issue?
04-12-2019

[~andrew] I'm not clear what the plan of action for this one is. It looks like JDK-8189762 is in 8u, but doesn't have changes to the JDK. Is there a plan to push this webrev? https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ It mentions JDK-8189762, but the connection to that bug eludes me. Am I missing something?
22-11-2019

Revised webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.01/ It has been reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010220.html
20-11-2019

This will need a revised webrev once the ClassFileInstaller test changes are backported to the jdk repository.
22-08-2019

Fix Request (11u) I would like to backport this patch to 11u, as it appears to be on Oracle's backport list. After Partial backport of JDK-8218266 (JDK-8222914), original patch applies cleanly. Backport discussion thread: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001529.html
15-08-2019

Fix Request (8u) I would like to backport this patch to 8u, as it appears to be on Oracle 8u backport list. The patch does not apply cleanly. The fix itself applies cleanly, but included test does not. Code review thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010023.html
12-08-2019