Question on layer/peeling

[Vitaly Davidovich]

So you'll have this issue if you change your class to be a value type and
yet continue to use non any-fied generic classes.  I think it's a pipe
dream if anyone thinks they'll simply change their class to be a value
type, and everything will be peachy.  Even if core JDK collection classes
get any-fied, you'll still have to make adjustments, such as moving over to
the methods that have multi-return (whichever approach Brian & co pick);
continuing to use get() will most likely not work properly.

More likely, people will have to introduce new value types that mirror
their old classes, update their APIs to work with specialized generics
properly, deprecate the old classes, and slowly move away from them.  Also,
in my experience on the .NET platform, there aren't that many value types
as a proportion of all types; certain domains (e.g. graphics, numerics)
will have higher counts of them, but most "general purpose" apps do not use
them heavily (custom structs, that is, I'm not counting the fact that
primitives in .NET are actually represented as value types).  I suspect the
same will be true in java; it's not like all of a sudden everything will be
a value type.  So for those types that are a good fit, a careful and
thought out migration plan will be needed.

On Tue, Jan 6, 2015 at 5:52 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
wrote:

>  That is my question as well. If Complex was a reference type that code
> would be null-safe. It would be weird if only changing Complex into a value
> type caused that code to start throwing NPEs and have the if-statement
> become dead code.
>
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
> *From:* Vitaly Davidovich <vitalyd at gmail.com>
> *Sent:* ‎Tuesday‎, ‎January‎ ‎6‎, ‎2015 ‎23‎:‎32
> *To:* Timo Kinnunen <timo.kinnunen at gmail.com>
> *Cc:* John Rose <john.r.rose at oracle.com>, valhalla-dev at openjdk.java.net
>
> Wouldn't you get an NPE here since you'd be auto unboxing a null into a
> value type? I'm a bit confused about what you're trying to demonstrate.
>
> Sent from my phone
> On Jan 6, 2015 5:24 PM, "Timo Kinnunen" <timo.kinnunen at gmail.com> wrote:
>
>> The type in bytecode will be Object, but the type in source code will be
>> V, with V=boxed complex number, for example. The idiom I’m thinking of is
>>
>>
>> Complex complex = numbers.get(nonexistentKey);
>>
>> if(complex == null) return;
>>
>> calculate(complex.re, complex.im);
>>
>>
>>
>>
>>
>>
>> (Complex is a value type, numbers is a Java 5 hash map)
>>
>>
>> --
>> Have a nice day,
>> Timo.
>>
>> Sent from Windows Mail
>>
>>
>>
>>
>>
>> From: John Rose
>> Sent: ‎Tuesday‎, ‎January‎ ‎6‎, ‎2015 ‎23‎:‎09
>> To: Timo Kinnunen
>> Cc: Brian Goetz, Michael Barker, valhalla-dev at openjdk.java.net
>>
>>
>>
>>
>>
>> On Jan 6, 2015, at 1:00 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
>> wrote:
>> >
>> > Before assigning semantics to x == null, let’s not forget boxing. What
>> will happen if x is a boxed value which was returned from a call to the
>> non-specialized Map.get(Object key) method?
>>
>> ?  Then the comparison will be false.  In any case the type of x there is
>> Object, isn't it, so there's nothing new here?  — John
>
>