RFR: JDK-8218630: CreateSymbols includes class and module headers unnecessarily.

[Joe Darcy]

PS I see that data is already out for review on a different thread:

https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012939.html
https://mail.openjdk.java.net/pipermail/build-dev/2019-February/024936.html

Thanks,

-Joe

On 2/7/2019 11:04 AM, Joe Darcy wrote:
> Hi Jan,
>
> Is the revised historical data also available for review?
>
> Thanks,
>
> -Joe
>
> On 2/7/2019 9:15 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Joe noted that the proposed historical data for JDK 12:
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>> may contain unnecessary items, and it indeed is the case.
>>
>> The main problems appear to be:
>> -when the class headers are being compared, the nestMembers for the 
>> current version may be null, and the nestMembers for the previous 
>> version may be an empty list. So, currently, such headers won't match 
>> and the header will be generated again to the historical record. 
>> listMatch can be used to consider null and empty list to be the same
>>
>> -module header descriptions may refer to 
>> RequiresDescription/ProvidesDescription, which are missing 
>> hashCode/equals, which means that headers that have either requires 
>> or provides won't match any of the existing headers. The fix is to 
>> add hashCode and equals
>>
>> I generated the ct.sym for the original JDK 12 historical data from
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>
>> and the historical data generated by this patch, and the resulting 
>> content appears to be equivalent.
>>
>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218630
>>
>> How does this look?
>>
>> Thanks,
>>     Jan