State of javac support for lworld-values.
srikanth.adayapalam at oracle.com
Mon Mar 26 08:29:34 UTC 2018
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
> 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.
More information about the valhalla-dev