+1
David
Sent from my iPhone
On Jul 12, 2013, at 3:15 PM, Richard Bair <richard.b...@oracle.com> 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
> https://javafx-jira.kenai.com/browse/RT-31565.
>
> Anybody with major heartburn let me know now, 'cause its going down!
>
> Richard
