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
