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

[Srikanth]

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 ACC_FLATTENABLE.
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