final abstract class

[Brian Goetz]

The changes to the compiler are simple enough.  As always, 
implementation is probably one of the lowest factors in considering an 
issue like this.

What you're working against is the "human factors" that is implicit in 
the naming chosen in 1996.  Abstract (in the context of a class) may 
mean "non-instantiable", but it also means "may have abstract methods", 
and the user's mental model of what abstract-ness means is closer to "I 
have to supply some method implementations" than "non-instantiable". 
With this meaning of abstract in mind, "abstract final" kind of sounds 
like an oxymoron.

When looking at a proposed language change, it is natural to focus on 
"if we had this feature, I could write this-and-such code, which is 
good."  Unfortunately, this is mostly looking in the wrong direction. 
You need to be looking at interactions with other features, what BAD 
code a feature might also enable, and how it affects the "shape" of the 
"language boundary" (more complex boundaries are harder to understand 
and more error-prone.)

The downside of a feature like this is the damage it does to the user's 
simplified mental model of what "abstract" means.  (Not to say I don't 
like the motivation -- I find having to write a private ctor to be an 
inelegant hack too.)


On 8/12/2012 1:08 AM, "Zdeněk Troníček" wrote:
> Hi,
>
> we cannot subclass a final class and cannot instantiate an abstract class.
> Why a combination of final and abstract is not allowed? Declaring a class
> final and abstract would express in elegant way what is now done by final
> and private constructor.
> (Certainly not a big thing but the required changes in javac does not seem
> to be large either.)
>
> Z.
>