Clarification on migration to value types and boxed vs unboxed representations

Richard Warburton richard.warburton at
Tue Jan 6 02:59:19 UTC 2015

Hi Brian,

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.

Sorry - still catching up on my reading backlog on this list.

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.")

Developers are incredibly unlikely to have read this javadoc line. I
imagine you already know this, but for posterity's sake it seemed worth
noting it.

I suspect that 3rd party library authors are in a more pickley situation
having not planned this through as clearly. Upside: they are probably
willing to do backwards incompatible releases where its a very corner-case
situation. I'm trying to think if I believe this to be worse than variables
called enum or implementations of List that had `List<T> sort(Comparator)`.

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.

Yup - definitely reasonable with LocalDate. I think the lock situation is
probably problematic for people who haven't explicitly caveated it in their
documentation - I can't see any sensible reason why you would do that but
someone, somewhere will have done so.


  Richard Warburton
  @RichardWarburto <>

More information about the valhalla-dev mailing list