Superclasses for inline classes

[Dan Smith]

A few of points in this thread emphasize differences between *declared* inline-friendly abstract classes and *implicitly* inline-friendly abstract classes.

> On Dec 20, 2019, at 2:11 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> - it has no synchronized methods
> 
> I think the natural way to phrase this is that the type itself does not
> admit synchronization, either via a synchronized method or a
> synchronized statement.  Then it’s a type system property rather
> than a structural property of methods.

If the class is declared inline-friendly, then sure, this is a check we can make.

If not, we can either:
- Infer from the use of 'synchronized' that this is *not* an inline-friendly class
- Call the class inline-friendly anyway, and let it blow up at run time

A compile-time error is not an option.

I lean towards the runtime error, because inferring a class property based on a random method modifier is too subtle.

Put another way, if you want strong checking for 'synchronized' (and I think we can safely call this an option, not a necessity), you also probably want some sort of explicit opt-in to inline friendliness.

>> Object, and all interfaces, would be inline-friendly (we can adjust the declaration of Object to meet this requirement); the compiler would structurally recognize abstract classes as inline-friendly and set the bits in the classfile.
> 
> I like this, as long as “structurally” includes some explicit signal either in the
> source code or (at least) in superclass (from which a new default would be
> silently inferred).  IMO there’s it’s hard to see a case for “promoting”
> apparently-empty constructors (like C(){}) into declaratively-empty ones.
> They would become invisibly-non-empty via action at a distance in supers
> and in field definitions.

Hmm, action at a distance is inevitable in the "just infer it" model. Somebody decides to add an innocent-seeming private field, and they've broken binary compatibility with their subclasses.

Are we being too clever? We need the class to give us a permanent guarantee about the API; but at the same time, we're hoping the author doesn't have to notice that they're making this promise. That may not be workable.

I kind of like your idea of a new flavor of constructor. If we drop the inference piece, it forces us to surface something in the language, but maybe it's subtle enough that, unlike a new flavor of class, it doesn't trip the "must include in Java 101" wire?