Clarification on migration to value types and boxed vs unboxed representations
richard.warburton at gmail.com
Tue Jan 6 02:59:19 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
>> 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
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
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.
More information about the valhalla-dev