Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

Also, you can just as well get lost writes with immutable objects if you
forget to reassign the variable with the result of a mutating operation.

Sent from my phone
On Jan 5, 2015 8:40 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Jan 5, 2015, at 5: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
> > }
>
> The simple answer:  It's party foul; show them the door.
>
> There are also tales of people synchronizing on interned strings and even
> interned integers.
>
> Code that does that is broken and needs to be identified.
>
> Value types are designed to refuse synchronization even if they are boxed
> into object wrappers.  If the javac compiler doesn't see the problem, the
> JVM will throw something like IllegalMonitorStateException.
>
> This is new behavior for objects, but it is far better than a conversion
> (explicit or implicit) which creates a temporary object that will silently
> accept a lock attempt.
>
> Refusing locks is also cheap and easy to implement.  (Unlike special
> processing for "==", which has its own kind of sadness.)
>
> > 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?
>
> Boxing them doesn't solve anything; it just moves the identity bug into an
> obscure place.
>
> > 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.
>
> Key question:  How did users experience the difference between the packed
> and the proxy version?
>
> In that design it might have been because of side effects viewed through a
> surprising alias (since packed values are manipulated by-reference).  Value
> types as proposed do not have that set of surprises, because they are
> immutable.
>
> Mutability plus unexpected aliasing causes race conditions and other bugs,
> which we want to avoid.
>
> (BTW, mutable structs plus by-value copying also causes lost writes, which
> is corner case in C# that we want to avoid.  Mutable = bad, sorry.)
>
> > 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?
>
> If you cast a value to Object you get a box.  Just like casting an int to
> an Object.  ("Codes like a class, works like an int.")  The syntax for
> naming the box-type for a value V is TBD; there are not many use cases for
> it.  (Bad bikeshed color of the moment:  V&Object.)
>
> — John