Moving from VVT to the L-world value types (LWVT)
srikanth.adayapalam at oracle.com
Tue Feb 13 12:48:42 UTC 2018
On Tuesday 13 February 2018 12:02 PM, Srikanth wrote:
> On Tuesday 13 February 2018 12:42 AM, John Rose wrote:
>> On Feb 12, 2018, at 8:53 AM, Srikanth
>> <srikanth.adayapalam at oracle.com> wrote:
>>> Hi Frederic,
>>> A couple of follow up questions below:
>>> On Monday 12 February 2018 10:02 PM, Frederic Parain wrote:
>>>> The current design allows null references for value types, as long
>>>> as they are not stored
>>>> in a container (field or array) declared as flattenable. This is a
>>>> significant change from
>>>> previous design. So, casting null to a value class type is now legal.
>>> OK. This does not call for any change to the specification of
>>> checkcast in JVMS ?
>>> (I don't know that it does - Just double checking)
>> There might be an option here: Maybe we could get away with having
>> throw NPE if the target class is a value type. After all, the
>> checkcast instruction resolves
>> its class operand. Remember that we *must* allow polluting nulls in
>> fields which
>> are not explicitly marked as flat, but *only* because of binary
>> compatibility requirements.
>> We *do not* allow polluting nulls to be stored into arrays, because
>> arrays *must*
>> resolve their element types before the first array is constructed. I
>> think we could
>> put checkcast into either of these two categories: Allowing
>> polluting nulls for
>> compatibility, or forbidding them (throwing NPE).
> OK, I have raised https://bugs.openjdk.java.net/browse/JDK-8197791 to
> track this issue from javac side.
> ATM, javac rejects such casts with error: incompatible types: <null>
> cannot be converted to ...
> I will work on it after the discussion settles down and there is
> clarity on the course of action.
Experimenting a bit more with this, I see that in the javac land, the
Types.isAssignable(Type t, Type s) and
Types.isCastable(Type t, Type s)
share the same innards viz, the TypeRelation "isSubtype".
As such, at the type system level it would appear to be
unsound/inconsistent to allow assignment of nulls to value type
instances while forbidding cast of nulls to value type instances.
I think they should behave the same way (allow) and any errors issued
either at compile time or at load/link/runtime need to be on account of
other decorations/modifiers/annotations influencing the outcome as
opposed to some choice at the type system level.
I think what javac ought to do is to align with the runtime behavior
wherever it can discern the same situation at compile time. At the
moment I am inclined to think casting nulls to value types in and off
itself should not result in an error, but only (maybe) on a subsequent
This needs to be weighed on by type system and runtime experts.
More information about the valhalla-dev