You have also the problem of people doing a lot of things in the constructor, by example
class Foo { @Stable final int x; Foo() { m(); x = 3; m(); } void m() { for(...) { // use x here } } } here, m() can be JITed with x equals to 0 as a constant and the code of m() be re-use for the second call even if the value of x has changed in the middle. in that case, either you need to maintain dependency between the JITed code and the field 'x' or have a bit saying if an object is fully initialized or not, this bit will be true at the end of the constructor and can be set for the de-serialization too. Rémi ----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Paul Sandoz" <paul.san...@oracle.com> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Jeudi 7 Décembre 2017 20:50:01 > Objet: Re: [10?] RFR: 8193128: Reduce number of implementation classes > returned by List/Set/Map.of() >> On Dec 6, 2017, at 5:16 PM, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> It can, since final fields are not treated as really final (unless in >> java.lang.invoke package, where it’s as if all such fields are annotated with >> @Stable). C2 will treat the field value a constant value if the collection is >> held in a static final field. > > We could tweak the semantics of @Stable to omit the zero corner case for a > final > field. Then the annotation on a non-array field would mean “trust this final”. > > It would be yet another stop gap before that far-off day when we fix finals > (and > arrays). Such new uses of @Stable would have to be evaluated for any > interaction with deserialization, so it’s not a simple decision.