As per this bug: https://github.com/FasterXML/jackson-dataformats-binary/issues/30
there is the issue that when using `uint32` type for numeric values above range of `int32` (that is, full 32-bit positive values, with high bit set), value may mutate even when bound as Java `long` which could express it accurately. Fixing this should be relatively easy, by exposing values as natively `long`s; that will still allow coercing back to `int` if and as necessary. However, I think there are two main possibilities here: 1. Always expose `uint32` values as Jackson `long` (`NumberValue.LONG`) 2. Only expose as long, if value does not actually fit `int32` (Java `int`) I think my intuition suggests that (1) may be less surprising to users. However, with JSON Jackson always uses smallest available type, which is essentially (2). What do you think? I am willing to go either way, if there is clear consensus. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
