RFR: JEP 367: Remove the Pack200 Tools and API
henry.jen at oracle.com
Thu Dec 5 08:16:12 UTC 2019
Updated webrev 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.
> 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.
> 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:
>>>> I think I have covered all the proposed fixes so far. This is the last iteration of the webrev , 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 
>>> 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 
>>> 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?
>>  http://cr.openjdk.java.net/~vromero/8234542/webrev.03/
More information about the core-libs-dev