DynamicForm.getValues() acts strange with Long values

[ispasov]

In a DynamicForm we use some FormItems that have Long values;

  DynamicForm form = new DynamicForm();
  Long big = 56789012344L;
  Long small = 11L;

  HiddenItem bigLong = new HiddenItem("bigLong");
  bigLong.setValue(big);

  HiddenItem smallLong = new HiddenItem("smallLong");
  smallLong.setValue(small);

  form.setFields(smallLong, bigLong);

The FormItem.setValue(Long longValue) method gets into the setValue(Object x) overload and gets into an if/elseif/... construct.
Because java.lang.Long is a java.lang.Number, we get into the corresponding branch and the value is stored as double into javascript's Number.

... //SmartGWT code
else if (value instanceof Number) {
            setValue(JSOHelper.doubleValue((Number) value));
...

Which is fine.

However DynamicForm.getValues() returns a LinkedHashMap with unpredictable object types!!!
I expect that if I put a Long in the form, I'd get it back as a Long. I was prepared to loose precision after 2^53 or so, but the change of the value type got me unprepared.

If the original longValue is outside Integer, then the corresponding key holds a Long (as expected) but if the longValue is small, then the corresponding key holds Integer, which breaks our code.

In the above example form.getValues() has an Integer "smallLong" and a Long "bigLong". In particular:

 (Long) form.getValues().get("smallLong");

throws a ClassCastException :(

We are using SmartClient Version: v10.0p_2015-01-26/LGPL Development Only (built 2015-01-26) and the issue is present in all browsers

[Isomorphic]

You'd end up with a similar exception in the reverse direction from assuming Integer when the user has entered a larger value. Just code generically using Number to avoid both issues.

[ispasov]

Thank you for the quick answer. The support here (even for LGPL users) is fantastic and this is one of the main reasons we chose SmartGWT.

Just code generically using Number to avoid both issues.

I can't assume Number everywhere:

new Criterion("bigLong", OperatorId.EQUALS, (XXX) values.get("bigLong"));

There is a Long and Integer overload of this method, but not Number or Object. If I put (Integer), I'll get an exception for larger values, if I put (Long), I'll get an exception for smaller values.
For this specific case, we are splitting the criterion creation in two:

Criterion crit = new Criterion("bigLong", OperatorId.EQUALS);
crit.setValue(values.get("bigLong"));

... and it works, getting though a Criterion.setValue(Object) overload.
However the same issue appears in various places since we started using Longs.

Can we guarantee that setValue and getValue will return the same (expected) Java type in some way?

[Isomorphic]

No, we have no plans to attempt to preserve the Java type, which would be a spectacularly large effort and make everything much more complex, slow and error prone, with almost no benefit.

If you'd like to free yourself of the ClassCastException circus, where meaningless type incompatibilities become fatal errors, you might consider migrating to SmartClient :)

In the meantime, we'll look at adding some more signatures that have Number to enable more generic programming in Java.

[ispasov]

In the meantime, we'll look at adding some more signatures that have Number to enable more generic programming in Java.

That would be great. I am sure more people will start using Longs and this will become a more common issue. Especially a Criterion constructor with Number should not add regression risk, because setValue already supports Number.

you might consider migrating to SmartClient :)

Yeah .... No. I am on SmartGWT exactly because I prefer the static typed paradigm for the project in hand.