JDK-8244763: Update --release 8 symbol information after JSR 337 MR3

[Jonathan Gibbons]

+1

-- Jon

On 6/26/20 6:13 AM, Jan Lahoda wrote:
> Hi,
>
> I propose to split the data update (for JDK 15 and for backports) and 
> the tool/CreateSymbols update (for JDK 16+). So I've created:
> https://bugs.openjdk.java.net/browse/JDK-8248405
>
> for the latter. Lets keep JDK-8244763 only for the former, i.e. for 
> this patch:
> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/
>
> I believe the data patch is reviewed, and is not controversial. Please 
> let me know if you see any issues with this split.
>
> Thanks,
>    Jan
>
> On 01. 06. 20 10:07, Jan Lahoda wrote:
>> Further testing revealed some issues with the patch, especially:
>> -use of un-encoded version when deleting the old data for the version 
>> (so the data deletion failed for versions > 9)
>> -need to delete old module data as well
>> -when searching for existing methods and fields, we need to continue 
>> the search to find the best existing candidate (the code still had a 
>> for loop break, so only the first match was found).
>>
>> I apologize for missing those in the first review.
>>
>> Delta webrev:
>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-01-create-symbols/
>>
>> Full updated webrev:
>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-create-symbols/
>>
>> Does this look OK?
>>
>> Thanks!
>>      Jan
>>
>> On 28. 05. 20 16:47, Jonathan Gibbons wrote:
>>> Looks good to me.
>>>
>>> -- Jon
>>>
>>> On 5/18/20 9:36 AM, Jan Lahoda wrote:
>>>> I apologize, I used a wrong patch for the "data" webrev. The "class 
>>>> name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is 
>>>> first adding field descriptions, and then removing the old ones:
>>>> ---
>>>>> class name java/util/jar/Attributes$Name
>>>>> field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> -field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name;---
>>>>
>>>> The correct order (and the order generated by the tool in the 
>>>> webrev.00-create-symbols/ webrev) is to first remove the field 
>>>> descriptions and then add the new ones:
>>>> ---
>>>>> class name java/util/jar/Attributes$Name
>>>>> -field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>> ---
>>>>
>>>> An updated webrev is the correct data is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/
>>>>
>>>> The only change is the above difference in order of entries in 
>>>> Attributes$Name.
>>>>
>>>> Sorry for trouble.
>>>>
>>>> Jan
>>>>
>>>> On 18. 05. 20 16:55, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We 
>>>>> should update the historical data for JDK 8 with these new APIs.
>>>>>
>>>>> As this was the first time we need to update data for a release 
>>>>> that other release data use as a baseline, it was necessary to 
>>>>> improve the CreateSymbols tool a little:
>>>>> -adding ability to ignore synchronized and native flags for 
>>>>> methods (as these don't affect the API)
>>>>> -when analyzing a new entry (method/field/class), and multiple 
>>>>> existing entries compatible with the new one exist, the existing 
>>>>> entry that matches the baseline is chosen (this helps to eliminate 
>>>>> unnecessary entries, esp. when the synchronized or native flag 
>>>>> changes)
>>>>> -when replacing/updating a release data, the original approach was 
>>>>> to remove the data for the release, and read them from classfiles, 
>>>>> and build the record again from scratch. This does not work well 
>>>>> for baseline data, so the new approach is:
>>>>> --keep all the existing data
>>>>> --the new data are load into a new auxiliary slot, called "$"
>>>>> --the old data for the given release are deleted
>>>>> --the auxiliary release is renamed from "$" to the correct release 
>>>>> name
>>>>>
>>>>> Together these changes allow to minimize the updates to JDK 8 
>>>>> data, to mostly only changes in the MR3, with some extra changes 
>>>>> like new/removed overrides (where the superclass has the method 
>>>>> that is/was overridden).
>>>>>
>>>>> The proposed changes to CreateSymbols are:
>>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-create-symbols/
>>>>>
>>>>> The proposed updates to the historical data are:
>>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-data/
>>>>>
>>>>> Note the changes only apply for JDK 8 historical data, so JDK 8 
>>>>> data are updated, and JDK 7 and 9 data undo the changes.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244763
>>>>>
>>>>> The intent is to backport to JDK 11u.
>>>>>
>>>>> How does this look?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Jan