Why is almost everything in the API final

[Christian Schudt]

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.

Christian


Am 02.09.2013 um 10:36 schrieb Artem Ananiev:

> 
> As Jonathan said, Richard is the best person to answer this question, but let me provide my own thoughts below as well.
> 
> On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote:
>> Hi,
>> 
>> Why is almost everything in the API final? OK, I understand there is a
>> security problem and not making things final could potential open security
>> holes.
> 
> It's not only about security. When API is final, it is easy to maintain and it is essential for backwards compatibility. Library developers know exactly, how classes and methods are used and how they can be evolved in the future. As a AWT/Swing maintainer I've seen many cases, when non-final classes were extended in a crazy way and used for absolutely different purposes than they were initially designed for.
> 
> Note that changing class/method/field from final to non-final is a backwards compatible change, but the reverse is not.
> 
>> What I'm puzzled about is that the rest of the JDK doesn't use this pattern
>> and so I wonder if it is still effective this way?
> 
> I'm sure if JDK developers didn't have to preserve backwards compatibility, they would be glad to make everything final :)
> 
>> I'm asking this because the penalties are significant, since you can not
>> easily extend the API because you can't subclass most framework classes.
> 
> Could you provide any examples, please?
> 
>> Thanks, best regards,
> 
> Thanks,
> 
> Artem