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.da...@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/
