Why is almost everything in the API final

[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