Why is almost everything in the API final
artem.ananiev at oracle.com
Mon Sep 2 01:36:55 PDT 2013
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:
> 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
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,
More information about the openjfx-dev