+1
In practice I agree with Richard that this should not cause any issues
for applications.
-- Kevin
David Ray wrote:
+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
