Re: Question on layer/peeling

[Timo Kinnunen]

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
Sent: ‎Tuesday‎, ‎January‎ ‎6‎, ‎2015 ‎23‎:‎32
To: Timo Kinnunen
Cc: John Rose, 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