PrimitiveObject interface

[Dan Smith]

A couple of notes from the EG meeting discussion.

> On Jan 5, 2021, at 12:11 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> We've wondered whether there are use cases to justify the second interface. Having gained some experience in this system, I think it's safe to say there will be. For example, an abstract class or interface extended by a family of primitive classes may wish to explicitly implement PrimitiveObject as a way to communicate a particular performance model, immutability, etc., to clients. Or certain primitive-like features, like operator overloading, may interact with libraries through type variables that extend PrimitiveObject. I also like the symmetry, which avoids any biasing of one side over the other.

Consensus that these use cases/arguments aren't strong enough to justify any major costs, but also as a nice-to-have, the costs don't seem very large. So, worth doing.

> Revised JVM behavior:
> - Primitive classes either get PrimitiveObject as an injected superinterface or reject classes without that superinterface. (Which one? TBD.)

Dan Heidinga expressed a preference for validation rather than injection, arguing that it's always simpler to validate. Fred Parain expressed a preference for injection, for uniformity with the treatment of IdentityObject. I guess that leaves us at TBD—maybe something we can check in on again when we've done some implementation.