RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration

[Roger Riggs]

On Fri, 9 Oct 2020 23:39:53 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> The existing value-based classes do not adhere to the new statements.
>> These changes are re-writing the spec after the fact.
>> Existing classes do not have to be final and can extend anything they want.
>
>> The existing value-based classes do not adhere to the new statements.
>> These changes are re-writing the spec after the fact.
>> Existing classes do not have to be final and can extend anything they want.
> 
> Yes, this is a deceptively-small-looking change to the spec for a large number of classes.
> 
> You'll have to clarify which classes you're concerned about, though. I just verified that all of the following classes
> are both `final` and extend an appropriate superclass:
> KeyValueHolder, MapN, Map1, SetN, Set12, ListN, List12, Optional, OptionalDouble, OptionalInt, OptionalLong,
> OffsetTime, ZonedDateTime, Duration, Instant, LocalDateTime, LocalTime, YearMonth, Year, MonthDay, OffsetDateTime,
> ZoneRegion, ZoneOffset, MinguoDate, HijrahDate, JapaneseDate, ThaiBuddhistDate, ProcessHandleImpl, Runtime.Version  (I
> stopped before digging into the ConstantDesc and foreign classes...)

I was most concerned about the primitive wrapper classes, that are not currently specified to be value based (currently
do not have references to ValueBased.html or similar statements).  The existing classes wrapper classes have some
explicit identity requirements in the JLS. Adding the @ValueBased annotation, with a javadoc reference to the updated
ValueBased.html would be a specification change. 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.

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

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