API REVIEW: RT-23888, Make PopupFeatures and PromptData final

[Tom Eugelink]

True. But does preventing this really make life that much easier? Even though the API cannot be subclassed, it still is used. So removing methods, or changing enums still causes binary incompatibility. Most of the "breaks compatibility" in that link are not prevented by making the class final.

In fact, I think it is highly debatable what causes more grief; inheriting a class and automatically swing along with API changes except on the part you have overridden, or proxy the class and having to incorporate each and every API change. And in the last case, you most likely will end up maintaining separate source code files for different JVM releases, because methods have been added (Java does not support a preprocessor to handle this).

Tom


On 2012-09-02 17:04, Tom Schindl wrote:
> >From a API provider point of view it is easier to evolve a final class
> because there can't be subclasses you can break.
>
> See http://wiki.eclipse.org/Evolving_Java-based_APIs_2
>
> Tom
>
> Am 31.08.12 15:03, schrieb Tom Eugelink:
>> All I can say is that I hate final classes. "Not meant" does not mean
>> "no one ever wants to".
>>
>> What is the gain of making them final and what is the loss of not making
>> them final?
>>
>> Tom
>>
>>
>>
>> On 2012-08-31 14:59, Peter Zhelezniakov wrote:
>>> Hello,
>>>
>>> There are two helper classes in javafx.scene.web package: PopupFeatures
>>> and PromptData. They are not meant to be extended by developers, so I
>>> hereby propose making them final, i.e.:
>>>
>>> public final class PopupFeatures {
>>>       public final boolean hasMenu();
>>>       public final boolean hasStatus();
>>>       public final boolean hasToolbar();
>>>       public final boolean isResizable();
>>> }
>>>
>>> public final class PromptData {
>>>       public PromptData(String message, String defaultValue);
>>>       public final String getMessage();
>>>       public final String getDefaultValue();
>>> }
>>>
>>> Thanks!
>