API bug(s) in Vaadin 7 after genericization

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.

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?

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

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.

Henri Sara: Could you create an enhancement request about this?

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.