L-world nullability migration
srikanth.adayapalam at oracle.com
Mon Mar 19 08:50:10 UTC 2018
I will require some clarifications in understanding the set of mails on
See below for questions/comments:
On Wednesday 14 March 2018 08:22 PM, Karen Kinnear wrote:
> I have been working through some of the migration issues with value
> field nullability
> and wanted to bounce some ideas off of folks.
> I think we are in agreement that the ideal world would make all value
> types flattenable -
> whether in fields or in arrays.
> I have been trying to walk through the details of the migration steps
> which we are all struggling with,
> with a possible approach of javac having a different permissiveness
> than the JVM.
> So - I think this is a tightly bounded problem. I think today this is
> limited to a very small list
> of value-based-classes. And perhaps in future there might be a handful
> of other classes that
> qualify for migrating from identity objects to value based objects.
While it may be possible to enumerate the set of value based classes in
JDK that can evolve into value types, I am assuming that we also need to
consider migration of types outside of JDK - in user land that may also
evolve into value types from having existed as classic reference types
earlier in third party libraries. And the VM may encounter these types
in classes that are not recompiled afresh -
Is this correct ??
> I was wondering if it were worth exploring distinguishing new value
> types from migrated objects at the language level. So for new value
> types - they would always be flattenable and javac should be strict.
I get why you would want to unburden the programmer from having to
always flag __Flattenable fields and have the flattening decision be
keyed off mere/very value-ness. John has also talked about at some point
flipping the default on __Flattenable.
But I don't think this has anything to with javac being strict or not -
right ? I think earlier discussions made it clear that in freshly
compiled code that is compiled at value-aware source level, null should
not be allowed to be assigned to value instances (whether flattenable or
otherwise), that null cannot be cast into a value type or be compared
with a value instance.
> There are no existing subclasses or clients for these objects, no
> existing APIs, no migration problem.
> So always flattenable, no need to use a modifier.
> Perhaps there is a way to give javac the information that a
> value-based-class is migrating to
> become a value type.
If it is only JDK classes that are of interest javac can maintain a
enumerated list of types - but I don't think that is the case - right ?
The way to do that for the general case would be via a modifier -
__ByValue per se does not say anything about whether the so flagged
class is a brand new value type or is one that is being evolved/migrated
from an earlier value-based avatar. So perhaps we need a
different/additional modifier such as __PureValue say.
> Value-based classes are supposed to have no identity today, so we are
> less concerned about
> catching identity issues. That said, we are talking about offering a
> flag to allow catching identity
> issues during JDK11. We are also talking about having javac catch
> these and runtime throw exceptions.
> Nullability is harder - because value-based classes are nullable
> today. That said, I think it might
> be helpful to offer a flag to catch nullability issues which takes a
> specific classname for runtime.
> Nullability might also require API changes.
> So one question is - what is javac’s role here? Warnings?
It is feasible that javac could have a lint mode to catch both identity
and nullability issues and emit diagnostics - at a release that predates
the eventual values fearures enablement.
For the chart, I will ignore the one below and share comments on the
version you have shared later.
> I think we have agreed that the JVM needs to handle the new classes
> and the migration, and that we currently have ACC_FLATTENABLE in the
> classfile to tell the JVM what behavior is expected by the container
> In practice - this is my model of migration.
>> On Mar 13, 2018, at 8:55 PM, John Rose <john.r.rose at oracle.com
>> <mailto:john.r.rose at oracle.com>> wrote:
>> On Mar 13, 2018, at 5:12 PM, Srikanth <srikanth.adayapalam at oracle.com
>> <mailto:srikanth.adayapalam at oracle.com>> wrote:
>>> For value arrays, I don't think there is anything that expressly
>>> needs to be handled by javac. I will double check.
>> (that seems true to me too)
>>> For nullability, my understanding is that expectations are different
>>> for javac and the VM. That javac should regardless of the
>>> flattenable/array element status, forbid injection of nulls.
>> Yep. The JVM is currently permissive about nulls, so that it can
>> easily run down-rev classfiles without surprises.
>> But that could change. In any case, javac should be non-permissive
>> when it is compiling valhalla code.
>> — John
More information about the valhalla-dev