RFR: 8254275: Development to revise "value-based class" & apply to wrappers

[Dan Smith]

On Tue, 13 Oct 2020 17:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> For JEP 390, the intention is to enable warnings, not to change the specification.
>> So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must be a future
>> aspirational statement, not a link to a current specification requirement.
>> I guess you may be concerning about the potential compatibility risks by this proposed spec change.  Of course JEP 390
>> can make spec change if discussed and agreed.    There is no behavioral change to the primitive wrapper classes except
>> the warnings are emitted if `synchronized` on these wrapper objects.   @RogerRiggs can you clarify more what you are
>> concerned about?
>
> Yes, the compatibility concern is foremost. We don't intend to change the behavior (yet) so the exact language used to
> describe what is being changed is important.  A simple assertion that Integer is ValueBased breaks compatibility. The
> JLS requirement for reference equality for small values is at odds with ValueBased.

To clarify my thinking on the identity/cacheing behavior of wrappers:

- Integer should claim to be a value-based class. I've made that part of this issue, and will include it in another
  iteration of the code.

- ValueBased.html needs to allow for factory methods that guarantee consistent identity for at least some results. It's
  okay to relax the definition of "value-based class" in this way—it doesn't change the contract of other value-based
  classes' factories, just gives them the option to do cacheing if they want.

- When Integer becomes a primitive class, the consistent identity guarantee of `Integer.valueOf` will continue to be
  true, and will extend to the full domain of Integers.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/222