Superclasses for inline classes

[Dan Smith]

> On Feb 11, 2020, at 4:54 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> Availability: Ideally, extending a suitable abstract class should be frictionless for inline class authors. In (2) and (3), the authors are blocked until the abstract class author opts in. In (4), the opt in is by default, although there's still a requirement that the abstract class be compiled with an appropriate source version.
> 
> In practice, if we require an opt in, this will be an obscure, little-used feature; or maybe it will become widespread, but we'll have introduced some new standard boilerplate into the language. If we don't require an opt in, inline classes will be free to extend most abstract classes automatically.

Dan H raised a good point about availability on the call today: some tools like to instrument constructors, including empty/default ones. If we recompile most of the abstract classes in the world to make them instrumentation-hostile (as is the case if they have ACC_ABSTRACT <init> methods), some of those tools are going to break, perhaps with no good workaround for the behavior they want.

So there's a trade-off: widespread inline-friendly abstract classes will make inline class authors happy, but instrumentation tools sad.

I don't have a sense of how serious this problem is, but it's something we should get a better handle on.