State of javac support for lworld-values.

[Srikanth]

On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
> It would also allow us all to start experiments with migration and 
> separation compilation,
> which would be helpful for the JVM, as well as informative for the 
> langtools strictness
> decisions.
>
> So this would explain why we are leaving existing bytecodes such as 
> checkcast and instanceof
> behavior alone. And request that you only put the null checks in for 
> statically known new value types.

I am summarizing the behavior of javac on tip for checkcast and instanceof

Casting nulls to __ByValue classes will be an error.

null instance of __ByValue class will be an error.

Casts of instances of Object or interface types being into __ByValue 
classes will have a null check inserted.

No null check inserted for instances of Object or interface types being 
queried for being instances of __ByValue classes.

Null assignment, null casting and instanceof checks of nulls all ideally 
should behave the same way - they use the same innards of javac. I have 
a feeling it would amount to an unsound type system to allow them to go 
their own ways.

Srikanth