FSInfo#getJarClassPath does not comply with the JAR specification
david.lloyd at redhat.com
Mon Oct 14 16:43:12 UTC 2019
The JAR specification specifies that the `Class-Path` attribute is a
space-separated sequence of relative URLs. A relative URL is defined
(, ) 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 .
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 ,
where the issue was discussed in depth.
 RFC 3986 § 4.2 - https://tools.ietf.org/html/rfc3986#section-4.2
More information about the compiler-dev