@ValueClass, to prepare a class for Valhalla transition (also immediately useful)

[kevinb9n]

When Valhalla lands, any library class trying to add value to its signature is going to face quite a few problems, which it could have addressed (and/or prompted its clients to address their part in) sooner, if the right help had been available.

Being able to mark such a class as @ValueClass or the like would signify "this class disavows identity", and would enable a set of analyses that could:

• defray a lot of that expense
• enables user code today to be forward-compatible with Valhalla, making the future transition nearly a "non-event"

For most analyzers, a big part of their support would simply be generalizing the checks they already do for Integer and friends, and then just "annotating" those classes with the new @ValueClass annotation. As always, they'd be free to act as they see fit, but for purposes of illustration here are some checks we might roughly expect:

Validations on the class itself:

• Is final
• All instance fields are final
• No instance methods are synchronized
• Superclass (if not Object) also has an explicit @ValueClass annotation

Validations on use sites:

• Synchronization
• Use of ==
• Use of identityHashCode
• Use of various methods that are themselves spec'd to use == (e.g. VarHandle.compareAndSet)
• Assigning to type Object (because it defeats the other validations just mentioned)

Note

I'd prefer to see the JDK offer the annotation and the warnings itself. However I think here is still an appropriate place for design discussions, which I hope the JDK folks would participate in and eventually decide whether to uplevel into their own planning.

Edit

This feature also delivers value immediately! These are classes for which identity dependency is already a bug. Protecting against those bugs is a part of the value proposition of Valhalla, but users don't necessarily have to wait for that.

[kevinb9n]

Is there a nullness connection here?

A weak one: type usages of @ValueClass types are higher priority to make null-aware, as they have more to gain, sooner, and also probably have a path toward streamlining their syntax (!) sooner than other types.

And sooner or later some value classes will be able to mark themselves as being "never-null", i.e. they are initialized an all-zeroes value and, well, can never be null. But, I suppose we'd need to know which ones those were; then warnings could be given for all nullable usages.

In all, probably not enough connection to slap the nullness label on this.