> 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.

Reply via email to