FSInfo#getJarClassPath does not comply with the JAR specification

[Jonathan Gibbons]

Generally, I think that the handling of Class-Path in javac, the 
handling in URLClassLoader [1],
and the specification should somehow all be brought into alignment.

-- Jon

[1] and any other usages in core-libs

On 10/23/19 10:07 PM, Jaikiran Pai wrote:
> Hello David,
>
> On 23/10/19 7:37 PM, David Lloyd wrote:
>> The bug ID never showed up for this.
> Given that there seems to be an acknowledgment, in this thread, that
> this current behaviour needs review, I took the liberty to file a bug in
> JBS https://bugs.openjdk.java.net/browse/JDK-8232925
>
> -Jaikiran
>
>
>>   Is this not acknowledged as a
>> bug?  And have you had any more thoughts about the specification's
>> take on `file` URLs?
>>
>> On Thu, Oct 17, 2019 at 11:08 AM David Lloyd <david.lloyd at redhat.com> wrote:
>>> How would you account for JDK-8216401 in this case?  Would you say
>>> that the specification should have been updated to account for the
>>> implementation?
>>>
>>> On Thu, Oct 17, 2019 at 9:34 AM Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> wrote:
>>>> Any changes/exceptions should be done in conjunction with updates to
>>>> specification.
>>>>
>>>> -- Jon
>>>>
>>>> On 10/17/19 6:04 AM, David Lloyd wrote:
>>>>> It seems reasonable to include the special exception for `file:` absolute URLs.
>>>>>
>>>>> I did file a bug at bugreport but I haven't yet received a
>>>>> notification that the bug was created. If I do, I will post the JIRA #
>>>>> here.
>>>>>
>>>>> On Wed, Oct 16, 2019 at 9:33 PM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>>>> One of the reasonsI hadn't done anything related to this in my proposed
>>>>>> change to FSInfo#getJarClassPath patch[1] was because I wasn't sure what
>>>>>> the actual expected semantics of the Class-Path attribute are.
>>>>>>
>>>>>> The jar Manifest documentation (which David pointed to) does state the
>>>>>> URI is to be relative, but I remember seeing a recent change discussed
>>>>>> in one of these mailing lists where absolute (file: scheme based) URIs
>>>>>> were supported. I finally found time to look through the JBS and here's
>>>>>> that issue https://bugs.openjdk.java.net/browse/JDK-8216401. So I think
>>>>>> whatever change we do here will then have to allow for absolute URI (for
>>>>>> file: scheme of local jars too).
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013760.html
>>>>>>
>>>>>> -Jaikiran
>>>>>>
>>>>>> On 14/10/19 10:13 PM, David Lloyd wrote:
>>>>>>> The JAR specification specifies that the `Class-Path` attribute is a
>>>>>>> space-separated sequence of relative URLs.  A relative URL is defined
>>>>>>> ([2], [3]) as a hierarchical URI with no scheme component.
>>>>>>>
>>>>>>> Relative URLs resemble file paths.  However they differ in some
>>>>>>> important ways: for example, a relative URL is URL-encoded, whereas a
>>>>>>> file path is not, causing problems when dealing with paths that have
>>>>>>> embedded spaces (among other things).  Relative URLs representing
>>>>>>> absolute paths on Windows have a form like `/C:/Foo/Bar`, whereas the
>>>>>>> corresponding file path would be `C:/Foo/Bar` or `C:\Foo\Bar`.
>>>>>>>
>>>>>>> Note (since this is a point of frequent confusion) that a relative URL
>>>>>>> can have an absolute path.
>>>>>>>
>>>>>>> AFAIK neither of these cases work correctly when javac interacts with
>>>>>>> a JAR that contains a `Class-Path` attribute.
>>>>>>>
>>>>>>> The current FSInfo code, as noted in the recent thread entitled
>>>>>>> `FSInfo#getJarClassPath throws an exception not declared in its throws
>>>>>>> clause`, reads the class path attribute value with code that uses
>>>>>>> FileSystems.getDefault().getPath(xxx) on each class path element [4].
>>>>>>>
>>>>>>> The correct behavior would be to wrap each item in a `java.net.URI`.
>>>>>>> If the syntax is invalid, report an error or skip the element.  Then
>>>>>>> determine if the URI is absolute; if it is, report an error or skip
>>>>>>> the element.  Finally, query the Path API to look up the file by URI
>>>>>>> using Path.of(uri) or similar, reporting an error or skipping the
>>>>>>> element if there's a problem.
>>>>>>>
>>>>>>> The less-elegant solution would be to manually URL-decode the string,
>>>>>>> and (on windows) manually check to see if there's a drive letter,
>>>>>>> removing the leading slash if there is one.  However I would consider
>>>>>>> this to be more likely to be bug-prone.
>>>>>>>
>>>>>>> This problem is the underlying cause of at least one Quarkus bug [5],
>>>>>>> where the issue was discussed in depth.
>>>>>>>
>>>>>>> [1] https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#class-path-attribute
>>>>>>> [2] RFC 3986 § 4.2 - https://tools.ietf.org/html/rfc3986#section-4.2
>>>>>>> [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URI.html
>>>>>>> [4] https://github.com/openjdk/jdk/blob/4ad3d82c76936a8927ed8a505689a3683144ad98/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java#L112
>>>>>>> [5] https://github.com/quarkusio/quarkus/issues/3592
>>>>>>>
>>>
>>> --
>>> - DML
>>