> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Dan Heidinga" <heidi...@redhat.com>
> Cc: "Kevin Bourrillion" <kev...@google.com>, "valhalla-spec-experts"
> <valhalla-spec-experts@openjdk.java.net>
> Sent: Monday, April 25, 2022 8:26:02 PM
> Subject: Re: [External] Foo / Foo.ref is a backward default; should be
> Foo.val /
> Foo
>>> What I’m thinking here about migration is that existing APIs can say
>>> “Optional”
>>> but field declarations can say Optional.val, getting additional footprint /
>>> flattening benefits, without perturbing the APIs (and with cheap
>>> conversions.)
>> Aren't most of the migration cases (at least for existing VBC)
>> targeting B2? They need to keep the reference semantics due to
>> existing code using null and will still get optimized inside a
>> compiled body.
> Sort of. For existing uses, we’re stuck with compatibility with the L
> protocol,
> certainly. But consider this example:
> class Foo {
> private Optional<Foo> f;
> public Optional<Foo> f() { return f; }
> }
> The API point has to stay LOptional, but the field could migrate further to
> QOptional, and there’s definitely value in that. With the current stake in the
> ground, we have no way to get there, but with Kevin’s proposal, we have the
> option to go further.
This seems very specific to Optional, for Optional storing null is always a
mistake, but that's not true for other VBC, by example a deadline can be typed
as an Instant with null meaning no deadline.
Rémi
