Nested ZipFileSystems cause issues with URI parsing

[Mitchell Skaggs]

Hi everyone,

I ran into a bit of a complex/niche issue, and I'm not surprised it wasn't
caught or brought up before. I have a situation brought on by Spring's
Uber-jars where a classpath resource is located inside of two jar files.
The standard getResourceAsStream, etc. works just fine because of a clever
implementation of URLStreamHandler that does some zipfile magic to find the
file offsets inside nested zips. Unfortunately, I need something more
powerful than an InputStream - I need java.nio.Paths - so I instead use
getResource and recursively consume that URI, opening/closing FileSystems
as needed. I expected that to work fine, but due to the way the URI is
processed by ZipFileSystem, it looks in the wrong place.

The cause of (and fix for) the issue:

After tracing through the code, here's what I believe to be the crux of the
issue: the ZipFileSystemProvider.getPath(URI) method. That method uses
String.indexOf on the string representation of the URI. Because of the
structure of jar-scheme URIs (link
<https://www.iana.org/assignments/uri-schemes/prov/jar>), it should instead
use String.lastIndexOf because the first "jar:" scheme is always paired
with the last "!/" separator. I believe this is a bug, and fixing it
wouldn't change behavior in situations without nested jar files.

Thanks,
Mitchell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200606/44f29f7a/attachment.htm>