Clarification on migration to value types and boxed vs unboxed representations

[Richard Warburton]

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>