+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
