Clarification on migration to value types and boxed vs unboxed representations

[Peter Levart]

On 01/06/2015 03:15 AM, Brian Goetz wrote:
>> 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.

Perhaps to accommodate gradual (opt-in for uses not for declarations) 
migration path, denoting the name of a class representing value type 
could still mean the "box" of it and denoting the actual value type 
would use special syntax.

Regards, Peter

>
> (As to the timing of boxing and unboxing, it would be exactly as 
> primitives today.)