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

Bradford Wetmore bradford.wetmore at oracle.com
Mon May 18 17:47:28 UTC 2020


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


More information about the compiler-dev mailing list