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 <[email protected]> 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?
