On May 15, 2018, at 12:35 PM, Dan Smith <daniel.sm...@oracle.com> wrote:
>
> I don't think it would be acceptable to change the meaning of code like this:
>
> LocalDate[] dates = new LocalDate[10];
> void set(int i, LocalDate d) { dates[i] = d; }
> boolean check(int i) { return dates[i] != null; }
>
> *Maybe* when it gets recompiled we force flattening and report an error on
> the comparison to null (there are other possibilities, but this is the
> strawman language design of record). But if migrating a class to a value
> class risks breakage like this everywhere in existing binaries, it's simply
> not a compatible change, and I would discourage anyone (including Java SE)
> from doing it.
>
> My vision of migration is a lot more inclusive: there are classes everywhere
> that meet the requirements for value classes. We want to give those classes a
> performance boost, for the benefit of the subset of clients who care,
> *without* disrupting the clients who just want a nice abstraction and don't
> have a performance bottleneck. We achieve this by encouraging widespread
> migration to value classes, and then managing semantics through some form of
> opt in: opt in, and you get the full performance benefit, but need to adjust
> for different semantics; remain opted out, and your semantics are stable
> (with perhaps some marginal performance gains).
I suppose Remi's annotation, including a non-flattening effect on arrays,
would meet the requirements you are posing here.
The non-flattening effect would be that the JVM, when loading the
annotated value type, would disable all flattening and enable
nullability for all heap variables including array elements.
For fields, the effect would be as if the declaring class did not
mention the type in the ValueTypes attribute. Remi is proposing
that javac in fact would *never* mention the annotated value
type in *any* local ValueTypes attribute.
You'd get nullability everywhere, and flattening *only* locally in optimized
code (but not in data structures or across virtual APIs). I guess it's
not too bad, if a type author has to opt into it with eyes wide open.
("Do or do not…")
Does that help?
For a prototype we could throw ICCE if (a) a ValueTypes attribute
causes loading of a class, and (b) it checks out as a value type
but in fact has the special annotation also. As a further exercise
it's worth asking if there is any value in allowing an annotated
value to to appear in a class's ValueTypes attribute, and what
that would mean; I hope we can avoid such fine distinctions.
— John
