JDK-8230501: Class data support for hidden classes

[forax at univ-mlv.fr]

> De: "mandy chung" <mandy.chung at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoyé: Vendredi 13 Novembre 2020 22:50:41
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On 11/13/20 12:32 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> No, the list will be unmodifiable not immutable, a List<Date> is a valid
>> argument but is not immutable because you can change the content of the each
>> date whenever you want.
>> Java only provides shallow unmodifiability not true immutability.

> The unmodifiable list can ensure that class data list behaves as if declared as
> private static final fields, one for each element. W.r.t the immutability,
> there is no difference to ConstantBootstraps::getStaticFinal on "private static
> final Date d".

>> Also, List.copyOf() doesn't allow null as element.

> This is good too. Why does one want a class list with null elements?
I want it, null is easy to check in term of bytecode and is aggressively propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by putting nulls in the right holes. 
It's also pretty useful when you have object that have a double representation, i.e. a value that can be a primitive value or a box, again testing if the box is null is a common operation. 

>> And, it will also makes classData() pretty useless as a BSM of a condy.

> I am also considering the single-item case and allowing Constable classdata
> (after I sent the mail). In which case, classData() can be used to return T
> (the given type) and classDataAt returns an element at the given index of the
> class data if it's a list.
If the object is Constable, it already has a bytecode representation, so there is no need to send it has a live object. 

> Mandy

Rémi