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/

Reply via email to