State of javac support for lworld-values.
srikanth.adayapalam at oracle.com
Mon Mar 26 07:48:06 UTC 2018
On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
>>> I would like to have a follow-up discussion about nullability of
>>> value types based on ACC_FLATTENABLE,
>>> and how to handle migration.
>>> The key points below that I want us to revisit are:
>>>> - Value instances may not be compared with == or !=. == and !=
>>>> cannot have any value operand(s)
>> This is a conservative choice. We could assign x.equals(y) as the
>> of x==y for x, y values. That's a language team choice, and I don't see
>> a decision on that coming soon. I recommend filing a tracking issue.
> Conservative for new value types.
Even for value based classes, instance comparison guidelines are clearly
spelled out in
Instances of a value-based class:
* make no use of identity-sensitive operations such as reference
equality (|==|) between instances, identity hash code of instances,
or synchronization on an instances's intrinsic lock;
* are considered equal solely based on|equals()|, not based on
reference equality (|==|);
A program may produce unpredictable results if it attempts to
distinguish two references to equal values of a value-based class,
whether directly via reference equality or indirectly via an appeal to
synchronization, identity hashing, serialization, or any other
identity-sensitive mechanism. Use of such identity-sensitive operations
on instances of value-based classes may have unpredictable effects and
should be avoided.
I think John's "We could assign x.equals(y) as the meaning of x==y for
x, y values. That's a language team choice" allusion is to "logical
candidates" in the original document:
(I realize that these guidelines are just that - they are not enforced
and we are likely to encounter code that violates them. So the proposal
to have a lint mode in jdk11 has merits)
More information about the valhalla-dev