Item.getItemProperty compiler warnings

Vaadin 6 / 7 / 8
1

How should we change our code to avoid the compiler warnings now that properties use parameterized types in Vaadin 7:

We have code like: (where the type is Button.class)
item.getItemProperty(“esf_unlockButton”).setValue(unlockButton);

This generates the following compiler warning:

Type safety: The method setValue(Object) belongs to the raw type Property. References to generic type Property should be parameterized

If I just get the item property and cast to the param type, such as:

Property buttonProp = item.getItemProperty(“esf_unlockButton”);

I can avoid the warning on setValue(), but I’ll just get a casting warning instead. Is there a correct way to code this or do we just have to suppress/ignore such warnings?

2

Bump.

I also didn’t find a way to set the value of a property without suppressing “unchecked”-warnings.
Is there a way to do this?
If it is mentioned somewhere then i’m sorry that i couldn’t find it and bumped an old thread.

3

Unfortunately, it is not possible to eliminate all such warnings without complicated cast chains that would only serve as a surrogate to suppressing warnings, and would not bring any additional type safety. It is better to suppress warnings for such casts.

This is partly due to the fact that an item can have properties of different types and partly due to significant limitations of what Java Generics support and don’t support.

4

I’m interested to know why Item.getItemProperty can’t return Property<?> instead of raw Property. In general, it’s almost never necessary to work with raw types.

Also, by adding a Class argument to Item.getItemProperty, it could avoid casting while at least adding some additional type safety by making it fail fast: it could check that the property type corresponds to the given Class and throw a ClassCastException if it isn’t. Using a raw type, the ClassCastException won’t happen until at some point one attempts to retrieve the value of the property and store it in a variable of the wrong type.

5

As a Property<?> cannot be cast directly to Property, this would often require extra double casts in user code:

Property<?> p1 = ..;
Property<String> p2 = (Property<String>)(Object)p1;

By contrast, a raw Property can be cast to a Property directly - even though that leads to a warning.

See also the discussion in
ticket #8791
. (I had to check the exact reason in the ticket as I couldn’t remember the cases where it is an issue, though I remembered there is an issue.)

Any changes to generics here would also need to be carefully checked in terms of what library and application code they break, whether in implementing or in using the interfaces. The version in which breaking changes would be would need to be selected carefully, possibly introducing such a change in a major version if the change was doable.

Do you mean an extra actual parameter to the method (public Property getItemProperty(Object propertyId, Class propertyClass))? What should happen then if a property is requested with the wrong combination of the class and property id?

Note that just a type parametrized method (public Property getItemProperty(Object propertyId)) without the class parameter in the method argument list would not provide any real type safety on the system level as different properties can have different types that can only really be checked at runtime, when type erasure has eliminated information about generics. Generics are just for compile-time checking and the method getItemProperty() could be called with the wrong combination of property ID and generic parameter. Thus, you would get the same ClassCastExceptions at runtime as without this mechanism.

6

I know, old thread and all but is there anything moving forward? In our project we have dozens of warnings due to uses of raw types. I don’t think generics add any value at this level. If I have any item and call getItemProperty(propId), how is there ever supposed to be generic type information available? The only way would be the mentioned Class parameter which has dubious benefits. The Item itself also cannot use a concrete generic type because it has to accept properties of all sorts of different types at once. Not even typed fields use a generic property (although they could, I guess), they also work with raw types. The more I look into it the more I wonder why this has been included at all. It seems, generics have been added for generics’ sake without ever having been tested or used.

7

I have same annoying warnings.
I think you can take care of warnings by providing generic method in Item class:

<R> Property<R> getItemPropertySafe(Object id) {
    // ...
}