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

[Stephen Colebourne]

On Wed, 14 Oct 2020 20:18:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references.
>
> In the text referring to ValueBase.html in many classes:
> 
> Is the "," misplaced.  Should it read:
> "not use instances for synchronization or unpredictable behavior may occur."
> 
> If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be
> less duplication between lots of classes and the explanation in ValueBased.html.

Can I suggest some additions?

* `java.time.temporal.ValueRange` - meets the criteria AFAICT

* `java.time.format.DecimalStyle` - meets the criteria AFAICT despite implementation internal cache of instances

* `java.time.Clock` subclasses - abstract base class equals/hashCode looks hostile, but JDK impls like `SystemClock` meet
  the criteria AFAICT

* `java.time.chrono.AbstractChronology` subclases - all five subclasses meet the criteria AFAICT

I don't think `java.time.temporal.WeekFields` meets the criteria as the factory promises "same instance", although it
is conceptually value-based.

`java.util.Currency` is conceptually value-based, but equals/hashCode isn't suitable at present - I think this should
be worked on, as currency is a key value-based concept.

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

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