State of javac support for lworld-values.

[Srikanth]

On Tuesday 27 March 2018 05:43 AM, John Rose wrote:
> On Mar 26, 2018, at 3:42 AM, Srikanth <srikanth.adayapalam at oracle.com 
> <mailto:srikanth.adayapalam at oracle.com>> wrote:
>>
>> On Monday 26 March 2018 04:00 PM, Srikanth wrote:
>>>
>>> Does a lenient mode at the eventual release for ease of migration 
>>> purposes amounts to foregoing the opportunity to slap on the wrists 
>>> but the lead the application programmer down the path to blowing 
>>> their entire foot (with a runtime error) ?
>>>
>>> (Has the VM considered not NPEing for a null reference assignment to 
>>> a flattenable field/value array cell, instead coalescing into the 
>>> default value ? Does that make sense ? Afterall, anewarray comes up 
>>> with default values)
>
> I don't think the VM should ever allow a type T to be defined as a 
> value type
> and then allow a heap variable of exact type T to be nulled.  To allow 
> that
> would be to constrain all future implementations of value types, to ease
> a few transient use cases.  Or, if not, it would constraint all future
> implementations to recognize three (not two) kinds of classes:  Objects,
> values, and object-like-values.

Could you elaborate ? If the vm were to treat assignment of nulls as 
though it was assignment of default value for value types (migrated or 
brand new) - I was not thinking of an alternate representation with 
extra storage for nullness encoding, only effectively bringing about 
assignment by default value - why would we end up with three kinds of 
classes ?

Wouldn't it be just Objects and object-like values ?

Thanks!
Srikanth