Nested ZipFileSystems cause issues with URI parsing

[Lance @ Oracle]

Hi Mitchell 

If you have a fix, please generate a diff  and a concise test to validate/demonstrate the issue/fix

Best,
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Jun 6, 2020, at 4:17 AM, Mitchell Skaggs <skaggsm333 at gmail.com> wrote:
> 
> 
> 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), 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/81e460a0/attachment.htm>