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