hg: valhalla/valhalla: [lworld] Introduce a new annotation java.lang.ValueBased to distinguish migrating value based classes from pure value types and implement leniet semantics for them; Also flip the default for ACC_Flattenable (original) (raw)

Srikanth srikanth.adayapalam at oracle.com
Wed Apr 4 00:42:44 UTC 2018

On Wednesday 04 April 2018 02:40 AM, Karen Kinnear wrote:

Srikanth,

I very much appreciate your introducing this experimental annotation. I do appreciate that you believe this is not how we will want to handle this in the long-term, and that we want to use javac as an early warning system to prevent in the field surprise behavior. I believe we need some experimentation with migration and nullability, to find out if there are benefits to incremental opt-in vs. immediate behavior changes. So this allows us to do those experiments using java and javac. If we never had separate compilation, I wouldn’t expect to need this. We will all learn more by trying concrete examples. Sounds good, I can see a lenient mode that only warns on null mix also as a long term option for @ValueBased classes. _- A field whose type is a pure value type can opt out of flattening by using the new field modifier NotFlattened _Did you mean NotFlattenable, i.e. nullable? My expectation was that at the classfile level, this would not generate ACCFLATTENABLE. I went with John's strawman for the experimental keyword i.e __NotFlattened. Yes, at the class file level this means not a new flag, but the absence of ACC_FLATTENABLE.

- Javac continues to implement a strict mode for pure value types (also see below) - The lenient mode for @ValueBased classes is only for null assignment and (the unrealistic) casting of nulls to @ValueBased types. All identity related violations still result in an error. So does comparison of @ValueBased type instances. (Rationale: Karen originally asked for null related violations to be tolerated on the grounds that the documentation for value based classes does not expressly forbid these. However since == and != are expressly called out as inadvisable operations on value based classes, I have continued to treat them as errors - but I can be convinced to relax this) My understanding of the model that John worked out was that == followed by null check and .equals pattern would work. If I understand what you are saying - that reflects what we may see at the bytecode level for backward compatibility. Not yet, I think the .equals call is not settled on yet, that is one of the proposals to attach a meaning to == and != and not the only one. As and when this gets finalized, I will follow up.

Srikanth

More information about the valhalla-dev mailing list