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

Jan Lahoda jan.lahoda at oracle.com
Fri Jun 26 13:13:06 UTC 2020


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


More information about the compiler-dev mailing list