Clarification on migration to value types and boxed vs unboxed representations
Brian Goetz
brian.goetz at oracle.com
Tue Jan 6 02:15:17 UTC 2015
> Obviously I may have missed some explanation in which case apologies but
> I'd just like to clarify the situation with respect to migrating existing
> value-like classes to value types. So let's suppose I've got a class (let's
> take java.time.LocalDate as an example) which morally should be a value
> type but isn't because the class predates the language feature. Its final,
> it isn't serializable or defines a serialization delegates, all its fields
> are final, the class is immutable. Looks like a great candidate to be
> converted into a value type and the preconditions seem to apply.
This what we call a /value-based/ class.
The question is, I believe, will it possible to (compatibly) migrate a
class that was a value-based reference class into a value type. We
certainly hope so, but we don't yet have a story for this, as I
mentioned the other day.
As John pointed out, we're pretty comfortable with the consequences for
synchronization (both the 310 classes an Optional refer to the
value-based disclaimer, which says "do this and you'll be sorry.") The
hard part about this migration compatibility is: nullability. (This is
where someone repeats the usual commercial for null-safe types and/or
elvii operators.) While null truly makes no sense for Optional, and I
could imagine being willing to hose code that relies on Optionals being
null, this is probably the exception among known value-based classes
(e.g., LocalDate). So while we may have a migration story for libraries
that dispense and receive formerly-value-based value types, we don't
have a story for migrating client code that might expect nullability for
those types.
(As to the timing of boxing and unboxing, it would be exactly as
primitives today.)
More information about the valhalla-dev
mailing list