FSInfo#getJarClassPath does not comply with the JAR specification

[Jaikiran Pai]

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
>