Why is almost everything in the API final

[Jonathan Giles]

Richard will answer this far more effectively than me, but because he is
midway through a long weekend I'll give a quick summary based on my
recollection.

The big issue is that with properties there are effectively two ways to
set or get values: you can of course call the getter or setter, or you
can do something like textProperty().get() / textProperty().set(..). Our
property implementation is essentially that the getter and setter
methods should do nothing more than defer to the property getters /
setters. Putting any logic into the getter / setter methods is actually
quite dangerous, as it can be easily avoided. For example, if
setText(...) were to do a whole range of calculations, these would never
be called if the end-user of the API were to call
textProperty().set(...) (or if the textProperty was bound to another
property).

Therefore, in providing getter / setter methods, we are simply providing
convenience API to end developers. If the end developer goes on to
override these methods in subclasses, only trouble can really come from
this: they will add in additional logic that may only be called in some
circumstances (and definitely never when the properties are used with
bindings).

There may be other concerns, but this is the primary issue that I can
recollect. If your intention is to subclass classes whose getters /
setters are final, you will need to change your approach to instead
listen to these properties from your subclass and react accordingly.

-- Jonathan

On 2/09/2013 11:55 a.m., 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.
> 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 asking this because the penalties are significant, since you can not
> easily extend the API because you can't subclass most framework classes.
>
> Thanks, best regards,
>