[PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs
brent.christian at oracle.com
Mon Mar 11 19:19:35 UTC 2019
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 , 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 to address your concerns.
For reference, the new relevant passages are:
"Invalid entries are ignored. Valid entries are resolved against the
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.
More information about the core-libs-dev