Inline Classes and extends

Brian Goetz brian.goetz at
Tue Dec 10 22:21:59 UTC 2019

As the document suggests, we are considering such treatment for Integer 
(and Number, ugh) and Optional.  While this surely has its own set of 
costs (supporting interface methods in `invokevirtual`, etc), this seems 
to be the lesser of evils compared to allowing inline classes to extend 
abstract classes (on which we'd need to imposes a complicated and 
hard-to-statically-check set of conditions.)  As you point out, if we 
have this tool in our box, then (combined with sealed types) it lets API 
designers compatibly evolve their APIs towards a more abstract 
representation, which seems like a beneficial direction.

There's no problem with non-public inline classes.  (The combination of 
public reference projection and private implementation class is expected 
to be a common one.)

On 12/10/2019 4:08 PM, Stephen Colebourne wrote:
> Is there any hope of rescuing superclass cases by converting the superclass
> to an interface?
> I'm particularly thinking of java.time.ZoneId and it's subclasses
> ZoneRegion and ZoneOffset. ZoneId had to be an abstract class originally as
> there were no sealed types, but it could be converted to a sealed interface
> in the future if that was a compatible change. Then the two subclasses
> could be inline classes (which they logically are). It also assumes we can
> have package scoped inline classes.
> I ask because the plan to convert the primitive box types to interfaces
> suggests ZoneId could be another candidate.
> Stephen
> On Tue, 10 Dec 2019, 18:24 John Rose, <john.r.rose at> wrote:
>> On Dec 10, 2019, at 10:17 AM, August Nagro <augustnagro at> wrote:
>>> One question I have is about `extends`. I understand that inline classes
>> cannot extend IdentityClass, but what about other inline classes? I have a
>> lot of classes that would make sense as inline, but are held back by their
>> superclass (which also could be inline).
>> One thing you get with the extra indirection of reference objects
>> is layout polymorphism, the power to have one type which points
>> at two or more distinct layouts.
>> If you get rid of the pointer (which is a must for inlines, so they
>> can “work like an int”), then you also lose the ability to represent
>> layout polymorphism.
>> It’s like in C++ when you try to mix inheritance and by-value storage
>> of instances:  Stuff goes wrong, awkwardly.
>> struct A { int x; }
>> struct B : public A { int y; }
>> A avar; avar.x = 1;
>> B bvar; bvar.x = 2; bvar.y = 3;
>> A anotheravar = bvar;  // what happened to the 3??
>> — John

More information about the valhalla-dev mailing list