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

Richard Bair richard.bair at
Fri Jul 12 13:15:50 PDT 2013

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!


More information about the openjfx-dev mailing list