> On Feb 11, 2020, at 4:54 PM, Dan Smith <daniel.sm...@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.
