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