State of javac support for lworld-values.
srikanth.adayapalam at oracle.com
Tue Mar 27 01:25:28 UTC 2018
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
> 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
Wouldn't it be just Objects and object-like values ?
More information about the valhalla-dev