Why is almost everything in the API final

[Stefan Fuchs]

Fabrizio Giudici wrote:
> On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt 
> <christian.schudt at gmx.de> wrote:
>
>> I agree with that and I also recommend to have a look at "Item 17: 
>> Design and document for inheritance or else prohibit it" from 
>> Effective Java.
>>
>> http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf 
>>
>>
>> It explains the burden and dangers of non-final design quite well.
>
> +1
>
>
-1

This applies only to the perfect (final) framework.
In other words for a framework without bugs and a framework, where all 
possible usecases are considered by its author.

I agree that there are dangers, when overwriting methods. But in my 
experience they rarely matter. Once created methods rarely change in a 
way that affects subclasses. And for major releases of the framework you 
have to test your application anyway.
If you develop a framework, where methods have complex interdependencies 
you should step back and write smaller, more manageable methods.

There are always legitimate reasons to overwrite methods. e.G.: To work 
around a bug in the framework. To trigger events, when a certain method 
has been called, to write debug info in a logfile,.... And no I don't 
want to roll out my own fork of jdk to my customers to do this....