A couple of notes from the EG meeting discussion. > On Jan 5, 2021, at 12:11 PM, Dan Smith <daniel.sm...@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.
