final abstract class

[Rémi Forax]

On 08/12/2012 09:04 PM, Brian Goetz wrote:
> 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.)

The other solution is to don't let the compiler generates a constructor 
if no constructor exists because a private constructor can still be 
called by reflection. Note that it fails in the same category of change 
that will be never done.

Rémi

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