RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

[Langer, Christoph]

Hi Alan,

thanks for your view on this backport request even though you aren't involved in jdk11u any longer.

> The support for zip files located in file systems created by custom
> providers was essentially a new feature in JDK 12 so it may not have got
> a lot of usage yet. There has been a lot of other improvements in zipfs
> in recent builds too and it's come a long way from its days as a demo
> file system. I don't have any involvement in JDK 11 updates but one
> suggestion is to x10 the testing of zipfs with a view to shaking out
> issues in the mainline before doing a refresh. That is, it might be
> saner to a bulk update after some bake time rather than picking out
> specific changes.

I think doing a bulk change to take over all the fixes that have been done on jdk.zipfs in the recent past seems quite appealing. Especially since those fixes don't break the Java API and probably don't even have CSRs associated.

For the moment, I need this change back in jdk11u because with the SapMachine 11 build of OpenJDK we'd like to ship the preliminary version of the POSIX permission feature to be used by a customer. And this fix is somehow a prerequisite because it enables the testcase we have there. Without the fix, a call to "Files.createFile(fs.getPath(name), PosixFilePermissions.asFileAttribute(perms));" would not work. Fixing this is a nice side effect of the change of 8034802. So we'd kill two birds with one stone here. As far as I can see, this fix is disjunct in its core from the other fixes made to jdk.zipfs.

However, for the jdk11u OpenJDK community I'd volunteer to do a bulk update of jdk.zipfs in the near future. Preferrably after we've come to a solution on 8213031 (POSIX permissions).

Thanks
Christoph