Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

Mutable structs aren't used all that often in c# but there are times when
they're very useful.  C# allows passing them by ref, which mitigates this
problem.  This also allows one to have large structs but avoid the copying
cost.

What's the plan to avoid such copying costs with proposed value types in
java?

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