Making Color Final (and Paint too, for all intents and purposes)

David Ray cognitionmission at
Fri Jul 12 16:05:24 PDT 2013



Sent from my iPhone

On Jul 12, 2013, at 3:15 PM, Richard Bair <richard.bair at> wrote:

> I have two different changes I might want to make, both of which are definitely incompatible for subclasses, but are otherwise source compatible. 
> public abstract class Paint {
>    Paint() { } // <--- Add this package constructor. Anybody who subclassed Paint will die
> }
> public final class Color extends Paint { … } // <---- Added final
> Nobody can do anything useful today by subclassing Paint. Each Paint subclass has hardcoded support in the graphics pipeline. If you were to subclass Paint with WackyPaint and use it in the scene graph, it would do absolutely nothing (except maybe explode in the graphics pipeline someplace). Likewise, if you extend Color with WackyColor, it will only be used as a Color object.
> Color however does have non-final methods (blast!) which somebody could override. Now, they could do nefarious things with it (as far as the graphics pipeline is concerned), but other than logging when somebody called a method, there is nothing else they could do by overriding (since Color is immutable), except for the deriveColor method which could be reimplemented in a reasonable manner, although the platform will never call your method so it doesn't do you much good.
> Both of these *should* have been final / effectively final when defined in the first place, and we've made subclassing these classes sufficiently worthless by other methods (other final methods plus the way the pipeline works) that nobody should really be broken but such a change. Besides which, we added a new abstract method in the last release which essentially breaks any subclasses in a binary manner (they would have to update their code), and I'm about to do it again while fixing
> Anybody with major heartburn let me know now, 'cause its going down!
> Richard

More information about the openjfx-dev mailing list