Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

Boxing it would just create subtle bugs as they'd be synchronizing on a new
local box on each invocation.  Not sure how to avoid that though if there's
existing code lime that.

Sent from my phone
On Jan 5, 2015 8:02 PM, "Richard Warburton" <richard.warburton at gmail.com>
wrote:

> Hi,
>
> 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.
>
> Unfortunately some party-pooper somewhere has written code like:
>
> LocalDate date = ...;
> synchronized(date) {
>   // Poop on party
> }
>
> By my reading of the current value types spec one wouldn't be allowed to
> convert LocalDate to a value type because there's no way to use intrinsic
> locks on a value type when it has no object header to stash information. It
> seems like there are other migration headaches as well because currently I
> can assign a LocalDate value to an Object variable. If value types don't
> subtype Object (and I'm presuming they won't and not claiming that they
> should) then any code which does this be in a bad place as well.
>
> I guess I got to this point in the email and then realised that you could
> just box the darn things and this would solve both problems. Does that make
> sense or am I completely misunderstanding things here?
>
> Its probably worth also noting at this point that about 18 months ago the
> LJC ran a hackday on the IBM Packed Objects proposal which has some overlap
> with value types. One of the things that people found most confusing was
> that packed objects had a transparent way of returning what was called a
> "proxy object". So that's like a boxed version of the packed object. It was
> not at all obvious when looking at the code that you wrote as to whether
> you were referring to the packed or the proxy object. I suppose part of
> that was not being able to easily refer to a spec - but part of it is just
> the general opaqueness of implicit conversions in general.
>
> Having a similar situation with value types would be a real shame. Would it
> be possible to clarify when value types become converted to their boxed
> equivalents?
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>