Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8232945

FSInfo#getJarClassPath does not comply with the JAR specification

    Details

    • Type: Bug
    • Status: New
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 11.0.5
    • Fix Version/s: None
    • Component/s: tools
    • Labels:
    • Subcomponent:
    • CPU:
      x86_64
    • OS:
      linux

      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


        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: