ZipPath drops leading file-path delimiter after upgrading to Zulu11.0.7 or later.

Problem:

File-path resolution (via ZipPath class) is no longer returning the leading file-path delimiter after upgrading to Zulu11.0.8.  This used to work in Zulu11.0.5.

For example, in Zulu11.0.5, it is working as expected:

C:\dev\testpath>C:\jdk\bin\java -jar build\libs\testpath.jar
fileN=xml
fileN=/xml/test.xml

For example, in Zulu11.0.8 it is not working as expected:

C:\dev\testpath>C:\jdk\bin\java -jar build\libs\testpath.jar
fileN=xml
fileN=xml/test.xml

This leads to incorrect file location.

 

Cause:

This is a known bug that was fixed with JDK-8211385.  However, the bug addresses earlier incorrect behavior where zipfs would return relative paths with a leading file-path delimiter (e.g. forward-slash).  This is incorrect because a path with the leading path delimiter represents an absolute pathname. So, the original expected behavior is actually incorrect and later versions of Java are working correctly.

 

Solution:

The last Zulu version with this "bug" is zulu11.35-jdk11.0.5.
The first Zulu version that has the JDK-8211385 fix is zulu11.39-jdk11.0.7.

It is recommended to change user code to adapt to the new (and correct) resultant relative path, and include a leading file-path delimiter whenever necessary to form an absolute path or concating 2 relative paths together.

Add Comment

Comments

0 comments

Please sign in to leave a comment.

Was this article helpful?
0 out of 0 found this helpful