[PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs

Brent Christian brent.christian at oracle.com
Mon Mar 11 19:19:35 UTC 2019

Hi, Jon

On 2/28/19 1:38 PM, Jonathan Gibbons wrote:
>> On 28/02/2019 20:58, Jonathan Gibbons wrote:
>>> Looking at the revised JAR specification, approved in [1], it is
>>> disappointing that the spec contains text which is specific to
>>> a JAR file being used in a classloader:
>>> |The resulting URLs are inserted into the search path of the class 
>>> loader opening the context JAR immediately following the path of the 
>>> context JAR. Any duplicated URLs are omitted.|
>>> That text would seem not to apply to javac and other tools that may wish
>>> to process the class files in a JAR file.
> |Agreed it might be good to fix it if possible. All the preceding text 
> is good, and can be handled by javac. The only questionable bit is the 
> text "Any duplicated URLs are omitted" which could be moved up a bit in 
> the spec to a new paragraph, and maybe rephrased to use "ignored" 
> instead of "omitted". If that were done, all the stuff about class 
> loaders could be taken as non-normative text.

I've updated the spec changes in the CSR[1] to address your concerns. 
For reference, the new relevant passages are:

"Invalid entries are ignored.  Valid entries are resolved against the 
context JAR.
If the resulting URL is invalid or refers to a resource that cannot be 
then it is ignored. Duplicate URLs are ignored.

The resulting URLs are inserted into the class path,
immediately following the URL of the context JAR.
For example, given the following class path:"

Let me know if this will work for javac, and I will proceed.


1. https://bugs.openjdk.java.net/browse/JDK-8217215

More information about the core-libs-dev mailing list