Why IntegerProperty implements Property and not Property?

Question

The Property interface added by JavaFX has a type parameter T, which is the type of the value wrapped by the property.

Among the implementations of the Property interface, there are some for numbers: IntegerProperty, FloatProperty, etc. All these classes implement Property<Number>.

Let's take IntegerProperty for example. What is the reason why it implements Property<Number> and not Property<Integer> as I would have expected?

Here is an UML diagram which clarify the hierarchy of IntegerProperty:

I have the weirdest sense of déjà vu. Have you asked this question before? — Kayaman, Jan 08 '16 at 10:44
@Kayaman No, never asked before. I've also done my best to check if someone else already did. — Paolo Fulgoni, Jan 08 '16 at 10:46
Possibly implemented like that to make it easier to bind number properties. See http://stackoverflow.com/q/28179293/1288408 — Modus Tollens, Jan 08 '16 at 10:53
Related question - http://stackoverflow.com/questions/34620552/why-does-longproperty-implement-propertynumber-but-not-propertylong I find the comments by @James_D in this linked question very informative. He also links this discussion - https://bugs.openjdk.java.net/browse/JDK-8125218 — Itai, Jan 08 '16 at 11:42
The generic treatment of numbers using the `Number` base class is always a bit tricky. But note that many casts (and thus, many errors) can easily be avoided: You often do **not** need to cast the value obtained from such a property, as in `Integer i = (Integer)p.getValue()`. Instead, you often can use the appropriate method, as in `Integer i = p.getValue().intValue();`. (This probably does not cover *all* cases, but most of them) — Marco13, Jan 08 '16 at 13:31

score 5 · Accepted Answer · edited May 23 '17 at 12:00

5

As mentioned in the comments section of a Java bug report (DoubleProperty has unexpected generics type),

This design is intended. It keeps the number of required methods significantly smaller.

In this answer's comments, James_D made me aware of a later bug report adressing that issue, ChangeListener cannot be added to SimpleIntegerProperty). The comment

We decided not to change the generics of primitive types properties (from Number to specific type) due to backward-compatibility issues. However, it means this issue cannot be fixed.

suggests that the team considered changing the design, but it was too late.

edited May 23 '17 at 12:00

Community

1
1

answered Jan 08 '16 at 11:53

Modus Tollens

5,083
3
38
46

3

I have to agree with the comment there by Randahl Isaksen: "Still, to me this seems to be an improper use of generics. Java developers who are used to generics will expect that a FruitCrate which uses generics is a Crate not a Crate – Itai Jan 08 '16 at 12:11
3

In much later comments from the JavaFX developer team (see e.g. http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-February/012739.html) you start to see references to "we tried to fix this but it was too late", which suggest to me that while it may have been intended, it was a mistake. There are other solutions that don't involve combinatorially exploding the API, e.g. `public abstract class NumberProperty implements Property` and `public class IntegerProperty extends NumerProperty`, as has been suggested by a number of people. – James_D Jan 08 '16 at 12:44

score 0 · Answer 2 · answered Jan 08 '16 at 10:57

I'd say that they use Number, so you can use those classes with AtomicInteger and BigInteger etc. as well.

As far as i can tell, the only "real" difference between DoubleProperty and IntegerProperty is the Method setValue(Number v) - one uses v.doubleValue(), the other v.intValue().

I don't have a working javafx environment here, so i can't test, if using IntegerProperty with a Double would throw an exception.

Why IntegerProperty implements Property and not Property?

2 Answers2

Linked