On Dec 16, 2020, at 11:07 AM, Dan Smith <daniel.sm...@oracle.com> wrote: > > I don't think we have a good answer right now, but it's something we will > want to address at some point. A solution would have to look like one of: > > - Ask clients (e.g., "is this a record?" code) to adapt to the presence of > the '$ref' class > - Modify reflection to hide the '$ref' superclass somehow > - Change the translation strategy to not disrupt the superclass hierarchy
The last is cleanest; the cost is resolving some technical debt in Valhalla, which is allowing more kinds of supers for primitive classes. There’s no firm reason, IMO, why Record could not be a super of both primitive and identity classes, all of which are proper records. Basically we need to make interfaces and abstract classes look a little more similar, with respect to the requirements of primitive classes. Spoiler alert: I think the final solution will endow abstract classes with *both* abstract and concrete constructors. The former will serve primitive classes and the latter will serve identity classes. Record will be such an abstract class. (Alternatively, and more clumsily, Record could be refactored as a proper interface, but sealed to PrimitiveRecord and IdentityRecord, and javac would translate to one or the other. The methods on JLO would not be defaults on record but would be duplicated on the two sealed subtypes.) — John
