Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
+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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
Hi Brad,
Thanks for your review and comments. I'll see if we can indent the
innerclass entries in the header (i.e. option 1) separately.
Jan
On 18. 05. 20 19:47, Bradford Wetmore wrote:
Thanks again Jan for looking into and fixing this.
I looked over the new entries last week, and the new MR3 ALPN/PSS items
looked good.
My only comment is that as a newbie to this area, the "header" attribute
includes the "innerclass" parameters: innerclass isn't an attribute on
its own which is what I originally thought.
In particular, our JCE javax.crypto.SealedObject implementation changed
between 7 and 8 with the addition of an internal lambda in our
implementation code (not part of the API).
static {
SharedSecrets.setJavaxCryptoSealedObjectAccess(
(obj,c) -> obj.getExtObjectInputStream(c));
}
AIUI, 8u is the baseline which includes the
class/header(+innerclass)/fields/methods attributes. 7u is restating
the class/header attributes (the same in the original .java class
definition), but didn't mention the innerclass "attribute" in the review.
This generated:
---begin---
8u
==
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
innerclass innerClass java/lang/invoke/MethodHandles$Lookup outerClass
java/lang/invoke/MethodHandles innerClassName Lookup flags 19
field name encodedParams descriptor [B flags 4
method name descriptor (Ljava...deleted...
7u
==
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
---end---
Jan explained privately that the header actually includes the
innerclass, so restating the header is sufficient, but that wasn't
intuitive to me without knowing that detail.
It would be more intuitive to me to see either:
1. innerclass indented a bit in the original JDK 8 code:
---begin---
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
innerclass innerClass java/lang/invoke/MethodHandles$Lookup
outerClass java/lang/invoke/MethodHandles innerClassName Lookup flags 19
---end---
or,
2. a delta "-innerclass" entry. e.g.
---begin---
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
-innerclass innerClass java/lang/invoke/MethodHandles$Lookup outerClass
---end---
but this may not be correct upon further contemplation.
Anyway, I approve the MR3 (ALPN/PSS) entries, but did not review the
symbol creation code.
Brad
On 5/18/2020 7:55 AM, 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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
Thanks again Jan for looking into and fixing this.
I looked over the new entries last week, and the new MR3 ALPN/PSS items
looked good.
My only comment is that as a newbie to this area, the "header" attribute
includes the "innerclass" parameters: innerclass isn't an attribute on
its own which is what I originally thought.
In particular, our JCE javax.crypto.SealedObject implementation changed
between 7 and 8 with the addition of an internal lambda in our
implementation code (not part of the API).
static {
SharedSecrets.setJavaxCryptoSealedObjectAccess(
(obj,c) -> obj.getExtObjectInputStream(c));
}
AIUI, 8u is the baseline which includes the
class/header(+innerclass)/fields/methods attributes. 7u is restating
the class/header attributes (the same in the original .java class
definition), but didn't mention the innerclass "attribute" in the review.
This generated:
---begin---
8u
==
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
innerclass innerClass java/lang/invoke/MethodHandles$Lookup outerClass
java/lang/invoke/MethodHandles innerClassName Lookup flags 19
field name encodedParams descriptor [B flags 4
method name descriptor (Ljava...deleted...
7u
==
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
---end---
Jan explained privately that the header actually includes the
innerclass, so restating the header is sufficient, but that wasn't
intuitive to me without knowing that detail.
It would be more intuitive to me to see either:
1. innerclass indented a bit in the original JDK 8 code:
---begin---
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
innerclass innerClass java/lang/invoke/MethodHandles$Lookup
outerClass java/lang/invoke/MethodHandles innerClassName Lookup flags 19
---end---
or,
2. a delta "-innerclass" entry. e.g.
---begin---
class name javax/crypto/SealedObject
header extends java/lang/Object implements java/io/Serializable flags 21
-innerclass innerClass java/lang/invoke/MethodHandles$Lookup outerClass
---end---
but this may not be correct upon further contemplation.
Anyway, I approve the MR3 (ALPN/PSS) entries, but did not review the
symbol creation code.
Brad
On 5/18/2020 7:55 AM, 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
Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3
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
