RFR: JEP 367: Remove the Pack200 Tools and API

[Henry Jen]

Hi,

Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up.

Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. 

The jar files are confusing in the webrev, but those files are removed. The whole test/jdk/tools/pack200 is removed.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/


> On Dec 2, 2019, at 6:50 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hi Vicente,
> 
> It looks like the update to make/data/symbols/symbols removes the jdk.pack module from the history JDKs 9, 10, and 11 when --release is used.
> 
> If that is the case, it would be incorrect since historically the jdk.pack module was present in those releases.
> 
> Thanks,
> 
> -Joe
> 
> On 11/22/2019 1:30 PM, Vicente Romero wrote:
>> Hi all,
>> 
>> On 11/22/19 3:21 AM, Alan Bateman wrote:
>>> 
>>> 
>>> On 21/11/2019 19:53, Vicente Romero wrote:
>>>> Hi,
>>>> 
>>>> I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in this one, the code hasn't been split into different webrevs. I'm also forwarding to build-dev as there are some build related changes too. The CSR for this change is at [2]
>>> Would it be possible to summarize what will remain in test/jdk/tools/pack200 after this removal? The webrev makes it looks like badattr.jar is being added but since it already exists then I'm not sure whether to believe it. pack200-verifier/data/golden.jar is another one as it looks like JAR file that is generated by the tests today is being checked in, maybe `hg add` in error?
>> 
>> I don't know why it is shown as added in the webrev, they have been removed. I have published another iteration of the webrev at [1]
>>> 
>>> The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, it's not immediately obvious to me which shared code compiled on Windows is impacted by this.
>> 
>> yes probably this change is risky. I did it as the comment suggested that the only reason the treatment for Windows was different was because of pack200. But not sure if we can trust that comment. Should I restore this code to its original state?
>>> 
>>> -Alan
>> 
>> 
>> Thanks,
>> Vicente
>> 
>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/