FSInfo#getJarClassPath does not comply with the JAR specification

[Jonathan Gibbons]

Hi David,

I haven't looked at this again recently.   I know there was an email
discussion a while back when the code for URLClassLoader was updated,
and I want to go back and review that thread.

In general, your comments about the FSInfo code are compelling, and
should be addressed. At that time, we should examine this related
issue about file: URLs.  And yes, the implementation should be in
accordance with the specification, and vice versa.

-- Jon

On 10/23/19 7:07 AM, David Lloyd wrote:
> The bug ID never showed up for this.  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
>
>