RFR: 8338626: CDS handling of JAR Class-Path attribute should allow / separator on Windows

[Alan Bateman]

On Wed, 11 Sep 2024 07:35:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Based on Calvin's description, and the definition of the `Class-path` attribute then the code to extract foo.jar should always be using `/` not `os::file_separator`, and then the classpath element should be constructed using `os::file_separator`.
>
> The Windows file API allows both `/` and ``. E.g., `os::open("foo/bar.jar", ...)` and `os::open("foo\\bar.jar", ...)` are equivalent. So in most cases, we just pass the path specified by the user to the OS, without doing any `/` to `` conversion. That's why both `java -cp foo/bar.jar` and `java -cp foo\bar.jar` work on Windows.
>  
> The bug in this particular case is: CDS needs to construct the path to a JAR file specified in the ClassPath attribute. As describe in the bug report, the test case is:
> 
> 
> java -cp foo/bar.jar
> 
> 
> and bar.jar contains
> 
> 
> Class-Path: lib.jar
> 
> 
> CDS needs to construct the string "foo\lib.jar". This is done by
> 
> - finding the directory that contains "foo/bar.jar" (which should be "foo")
> - appending "\lib.jar" to this directory (which gives us "foo\lib.jar")
> 
> The bug is that CDS fails to find the "foo" directory. This is BEFORE any processing of the ClassPath attribute of bar.jar itself.
> 
> The fix is -- to be able to find the  directory name, we need to find the longest prefix of the input that ends with either "/" or "".

`foo/bar.jar` is a relative file path. `lib.jar` is a relative URL. On the surface it might appear that they can be combined but there are many reasons why this can't work in general. So if the code is in the VM then it's always going to be approximation to how this JAR file attribute is handled by the application class loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20924#discussion_r1754269147