API bug(s) in Vaadin 7 after genericization

Vaadin 6 / 7 / 8
1

In Vaadin 7 the
Property
 class is now genericized (horray).

However, there are still some API updates that need to be done. For example,

Item.addItemProperty(Object id, Property property)

needs to be converted to:

Item.addItemProperty(Object id, Property<?> property)

Basically, anywhere in the source code that the string
Property
 is followed by a space character need to be fixed.

2

I would consider this an enhancement rather than a bug, but good to do nevertheless.

Some of the remaining cases are probably there because it has been unclear (during the quick first phase of the conversion process) whether something more specific can be used or not and what it would require from other parts of the data APIs. Other cases clearly could and should use the “<?>” suffix, though.

There is an older ticket (
#5731
) about using generics more, but it addresses primarily other parts of APIs and some of its parts are already obsolete/addressed.

Could you
create an enhancement request
 about this?

3

No, I think this is definitely a bug, because it causes a compiler error for the developer.

If I create a class like this:

public class FooItem implements Item {

        @Override
        public boolean addItemProperty(Object id, Property<?> property) {
            // blah blah
        }
}

which is the
correct
 way to declare that method, then my build fails with this compiler error:

FooItem.java:19: FooItem is not abstract and does not override abstract method addItemProperty(java.lang.Object,com.vaadin.data.Property) in com.vaadin.data.Item
    public class FooItem implements Item {
           ^
FooItem.java:21: method does not override or implement a method from a supertype
        @Override

In my experience with genericization, it’s an “all or nothing” thing. You can’t do it half-way.

I will try create a patch and file an issue.

Thanks.

4

I created
ticket #8791
 and included a patch.

There is a good deal more genericization work to be done. For example,
AbstractField
 should really have two generic type parameters, one for the field type and one for the underlying “converted” type.
Property.Viewer
 should have a generic type. Etc.

Thanks.