[API Review] Property and expression conversion methods

Martin Sladecek martin.sladecek at oracle.com
Tue Feb 19 02:03:02 PST 2013

On 18.2.2013 22:39, Knut Arne Vedaa wrote:
> Martin Sladecek wrote:
>> Hello,
>> there are 2 JIRA issues requesting some conversion between primitive
>> expression/properties/observablevalues and theirs object counterparts,
>> as primitive types actually use Number as generics parameter. To avoid
>> backwards incompatibility by changing the generics parameters to more
>> specific types, we decided to introduce conversion methods to these
>> types, so that you can use them as objects of the same (generics) type.
>> Here are the JIRA issues:
>> http://javafx-jira.kenai.com/browse/RT-25996
>> http://javafx-jira.kenai.com/browse/RT-19020
> It seems to me that the root problem here is this:
> interface ObservableNumberValue extends ObservableValue<java.lang.Number>
> interface ObservableIntegerValue extends ObservableNumberValue
> Wouldn't it be solved by changing it to:
> interface ObservableNumberValue<T extends java.lang.Number> extends 
> ObservableValue<T>
> interface ObservableIntegerValue extends ObservableNumberValue<Integer>
> (And similar for other Number descendants.)
> Knut Arne Vedaa

Yes, this is exactly the cause of all this issues. But changing this 
would result in significant amount of API incompatibilities and most of 
the applications won't be compilable after this change (it's not only 
the ObservableValue, it would spread to all subclasses). The compiler 
checks would be more strict, so e.g. new KeyValue(someDoubleProperty(), 
0) would generate an error and would need to be changed to new 
KeyValue(someDoubleProperty(), 0.0). Also, some people use bidirectional 
bindings between integer and double properties, this would be impossible 
after the change (now both properties are Property<Number>).

There would be also one ABI incompatibility, possibly breaking the old 
code, if setValue(Number) is called with some different Number type than 
the actual Number type the property represents, e.g. calling setNumber 
with Integer on a DoubleProperty is OK now (as Integer is a Number), but 
would result is ClassCastException after the change.

Because of these issues, we decided to introduce conversion methods 
instead of breaking the compatibility.


More information about the openjfx-dev mailing list