AutoBeanCodex problems

[Jordi Planadecursach]

I detected at least 2 bugs with the AutoCodex feature:

When trying to deserialize a Collection out of JSON it fails because
there are 2 coders in the stack.

When trying to deserialize a Long it fails too.

Eg:
CalueCodex.java:132

LONG(Long.class, long.class, 0L) {
@Override
public Long decode(Class<?> clazz, Splittable value) {
return Long.parseLong(value.asString());
}

value (JSONSplittable) = "2.0"
value.asString() = null

which ends up throwing NumberFormatException("null");

Is it an experimental version or something?

Cheers,
Jordi.

[Jordi Planadecursach]

This only happens when the JSON looks like:
{"thisIsANumber":2}
When the case is that it works well:
{"thisIsANumber":"2"}

[Colin Alworth]

Long values cannot be sent as a number over JSON, because JavaScript only support smaller numbers. If you only need Double or Integer precision, then declare that in your autobean, and you can be sure that JSON will pass those values correctly. GWT automatically allows you to create values as strings and will interpret them as long values, but won't let you make the mistake of trying to store long values in a way that will lose data.

To prove this to yourself, try looking at very large numbers in Javascript, like running alert(a111111111111111111) to see the lost precision as it converts to a double, or trying 1 << 30 and 1<< 40, and seeing that the values don't keep going up, but wrap around.

[Thomas Broyer]

On Wednesday, January 25, 2012 8:01:15 PM UTC+1, Jordi Planadecursach wrote:

This only happens when the JSON looks like:
  {"thisIsANumber":2}
When the case is that it works well:
  {"thisIsANumber":"2"}

See http://code.google.com/p/google-web-toolkit/issues/detail?id=6331 

[Thomas Broyer]

On Thu, Jan 26, 2012 at 11:52 AM, Jordi Planadecursach
<plan...@gmail.com> wrote:
> So then it is a problem of: org.JSON library which I use for
> serialization:
>
>   new JSONObject(myBeanWithLongs).toString()
>
> That converts Long -> non string number.

Yes and no.

JSON (RFC 4627) doesn't make any restriction on the value range for
numbers, so the org.json library is right in not serializing longs
into strings. But JSON also says "An implementation may set limits on
the range of numbers." Given that numbers in JavaScript are IEEE 754
binary64 values (equivalent of a Java double), and JsonUtils (used by
AutoBeans) uses native JSON.parse() or a fallback on eval(), then
numbers in the parsed JSON have to fit in a JS Number / Java double.
Because all Java longs do not fit in a Java double, AutoBean encodes
longs as strings, and therefore expects them to be strings (or in the
proposed patch, follows Postel's law by always serializing as strings,
but accepting numbers and strings for deserialization.

> The problem of unserializing collections with AutoBean codex persists.
> The workaround is to use a List. Then it works well.

AutoBeans only supports Lists and Sets as collection types:
http://code.google.com/p/google-web-toolkit/wiki/AutoBean#Property_types