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 <init> 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
