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

[Lindenmaier, Goetz]

Hi Christoph,

Patching the file myself really helped to see there are no real changes.

For the missing patch of the constructor I understand it was only an arbitrary reordering of arguments you omitted. Thus the whole chunk disappeared. This makes sense, and in case someone downports the other change he should be able to cope with that.

Thus, looks good!

Best regards, 
  Götz

> -----Original Message-----
> From: Langer, Christoph
> Sent: Friday, January 25, 2019 11:40 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE
> when the zip file is located in a custom file system
> 
> Hi Goetz,
> 
> >
> > And I see much more differences if I compare the diffs.
> >
> > Please explain.
> >
> 
> unfortunately, the udiffs of the webrev look different in quite some parts to
> what you see when you look at the commit on the hg web server
> (http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5), although those are
> the same. There were only 3 rejects when I applied the change to jdk11u
> (you could try this yourself).
> 
> > This is a big change, and it seems a lot more changed than resolving
> > Hunks.  Some hunks are missing altogether.
> >
> > For example,
> > http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5,
> > ZipFileSystem 2341
> > 2.341-            IndexNode inode = new IndexNode(cen, nlen, pos);
> > 2.342+            IndexNode inode = new IndexNode(cen, pos, nlen);
> > Is missing in your change.
> 
> The constructor IndexNode(byte[] cen, int noff, int nlen, int pos) (jdk11u) vs.
> IndexNode(byte[] cen, int pos, int nlen) (jdk11) was actually the part where
> the failing hunks originated. There was another patch pre 8034802 in jdk12
> which changed signature:
> IndexNode(byte[] cen, int noff, int nlen, int pos) -to IndexNode(byte[] cen,
> int nlen, int pos).
> 8034802 did this change then:
> IndexNode(byte[] cen, int nlen, int pos) -> IndexNode(byte[] cen, int pos, int
> nlen)
> 
> I chose not to touch this part but maybe this change should change the
> constructor from IndexNode(byte[] cen, int noff, int nlen, int pos) ->
> IndexNode(byte[] cen, int noff, int pos, int nlen), though, to take over this
> change of order in arguments. It's a package private constructor that is only
> called in one spot. What do you think?
> 
> Thanks & Best regards
> Christoph