Clarification on migration to value types and boxed vs unboxed representations

Brian Goetz brian.goetz at
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