JDK-8232945 : FSInfo#getJarClassPath does not comply with the JAR specification
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 11.0.5
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-10-16
  • Updated: 2021-02-05
  • Resolved: 2021-02-05
Related Reports
Duplicate :  
Description
A DESCRIPTION OF THE PROBLEM :
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


REGRESSION : Last worked in version 8

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Should be reproducible by providing a JAR file containing a class path entry such as `/C:/...` to `javac` on Windows.  Also should be reproducible by providing a JAR with class path entries using URL encoding.  The classes in the JARs will not be seen; there may also be an exception.


FREQUENCY : always



Comments
FYI - this is being discussed here https://bugs.openjdk.java.net/browse/JDK-8232925
24-10-2019