Verify ZipFile against upstream OpenJDK 8u121-b13

Updates the Android change markers to match the standard structure,
group common sets of changes and where necessary provide more
background information, bug references, etc.

FTR Upstream 9+181 has reimplemented ZipFile in pure Java instead of
part Java, part native. The pure Java implementation addresses or
simply avoids some of the issues for which we have added patches making
those patches obsolete; assuming of course that we can take the pure
Java implementation.

The following patches will become unnecessary after upgrading to 9+181.
* Do not use unlink() to implement OPEN_DELETE.
  - This was added because of a problem on fuse fs based file systems,
    specifically the /storage/emulated/0/ system where calling unlink()
    caused problems with lseek(). The pure Java implementation does not
    use unlink() instead it calls file.delete() on the Zip file after
    opening similar to this patch.

* initIDs() not used on Android.
  - The pure Java implementation does not have these native methods
    either.

* Always use mmap.
  - The Android native implementation only supports use of mmap. The
    pure Java implementation does not use mmap at all.

* Always throw an exception when reading from closed zipfile.
  - This was added during OpenJDK integration to maintain compatibility
    with both luni tests and also to remain compliant with the JavaDoc
    for the InputStream.read(byte[], int, int) method which states that
    it should throw an IOException if the stream had been closed. The
    upstream 8u121-b13 behavior was a bug. The pure Java implementation
    is similar to this Android patch.

* Provide access to underlying file descriptor for testing.
  - This was added to test a ZipFile change that was made to workaround
    the problem caused when a ZipFile was created but not closed in the
    zygote and so ended up with the same file descriptor being used in
    multiple processes. The problem arose when two of more processes
    attempted to read relative to, or othewise update, the fd's file
    offset causing a data race. The temporary workaround was to avoid
    using any calls that used or modified the file offset. This change
    was made to allow a test to verify that the file offset was not
    changed while accessing the file contents.

    Since the workaround was added more comprehensive fixes for the
    problem of what to do with fds open when forking the zygote have
    been made; see b/30963384. As a result this change is no longer
    needed and can be reverted. b/111148957 has been opened to track
    that work. The pure Java version would necessitate the removal
    of this change as this change relies on native access to the
    underlying file descriptor.

* Find entry by name, falling back to name/ if cannot be found.
  - This was added while updating ClassPathURLStreamHandler to replace
    uses of StrictJarFile with JarFile; change e8e4da2f. It was needed
    to maintain backwards compatibility with a change added in
    b/22527772. It should be possible to remove this patch after
    upgrading to 8u144 or above barring any app compatibility issues
    arising; see b/111293098 for more details.

The remaining changes should be self explanatory apart from this one:
* Error out early if the file is too short or non-existent.
  - This was added in two separate changes. The first was change
    adc40417 which according to the commit message was done, along with
    a couple of other changes, to fix a unit test. Exactly what unit
    test is not clear in the commit message.

    The second was change d95a9080 which added special handling of a
    non-existent file in order to maintain backwards compatibility and
    an accompanying test.

    Removing this whole block seems to have no effect on any of our
    unit tests. The test added under d95a9080 still works and contrary
    to the commit message of adc40417 no other unit tests fail.

    It is possible that this change can be removed without any adverse
    side effects. However, that change will be done separately as a
    follow on to this so that in the event it is needed it can be
    easily reverted as it will not lose any important change markers.

Bug: 111061052
Test: checkbuild - no functional changes
Change-Id: I9cfc124806989ec3042457e66096287e531e0ca5

0 files changed, 0 insertions, 0 deletions