The numeric codec implementations are currently strict in that they will only decode the exact BSON type corresponding to the Java type of the codec. For instance, the LongCodec will decode BSON Int64 but fail for all other numeric BSON types. This was ok when the codecs were only used in the context of org.bson.Document because DocumentCodec selects the right codec based on the BSON type of the value.

In the context of POJO or case case codecs this become problematic. It's likely that users will define a POJO or class class with one numeric type but expect to decode multiple BSON numeric types with a single codec based on the field type. For instance, a POJO with a field of type long will need to decode a BSON Int32 value into that field, even though it will encode the value as an Int64 on the way out.