[8u] RFR backport JDK-7143743 : (zipfs) Potential memory leak with zip provider

[Andrew John Hughes]

On 25/01/2020 06:48, Langer, Christoph wrote:
> Hi,
> 
>> There's a script that tries to adapt the exported patch to 8u (I've lost track of
>> where it is, perhaps someone can point to it)
> 
> The script can be found in the jdk9 or jdk10 repos, e.g. here:
> http://hg.openjdk.java.net/jdk10/jdk10/file/62306e615de1/common/bin/unshuffle_patch.sh
> 
> Maybe one should submit it to the jdk8u-dev repository? This would be the place where it's used currently...
> 
> Some documentation can be found here: http://cr.openjdk.java.net/~chegar/docs/portingScript.html
> 
> Cheers
> Christoph
>  
> 

You actually need two scripts for jdk10+ patches:

* jdk11/bin/unshuffle_patch.sh to move files back into the multi-repo system

$ sh ../jdk11/bin/unshuffle_patch.sh
ERROR: Invalid number of arguments.
Usage: ../jdk11/bin/unshuffle_patch.sh [-h|--help] [-v|--verbose]
[-to9|-to10] [-r <repo>] <input_patch> <output_patch>
where:
  -to9            create patches appropriate for a JDK 9 source tree
                  When going to 9, the output patches will be suffixed
with the
                  repo name
  -to10           create patches appropriate for a JDK 10 source tree
  -r <repo>       specify repo for source patch, set to 'top' for top repo
  <input_patch>   is the input patch file, that needs shuffling/unshuffling
  <output_patch>  is the updated patch file

* jdk9/common/bin/unshuffle_patch.sh to revert the modularisation changes

$ sh ../jdk9/common/bin/unshuffle_patch.sh
ERROR: Invalid number of arguments.
Usage: ../jdk9/common/bin/unshuffle_patch.sh [-h|--help] [-v|--verbose]
<repo> <input_patch> <output_patch>
where:
  <repo>          is one of: corba, jaxp, jaxws, jdk, langtools, nashorn
                  [Note: patches from other repos do not need updating]
  <input_patch>   is the input patch file, that needs shuffling/unshuffling
  <output_patch>  is the updated patch file

It might be worth bringing at least the 9 one into 8u, where it can be
maintained. I hadn't thought about that. The 11u one is trickier,
because then two copies would have to be maintained (the one in 11u &
the one in 8u). With the 9u one, it's effectively just rotting in that
unmaintained repository and I guess most people don't have 9 checked out.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew