@JsonDeserialize(contentAs = classOf[java.lang.Integer]) on the offending member.
Scala, unlike Java, supports using primitive types as type arguments to generic classes. However, this is not supported by the JVM; there is no way to represent
java.lang.List<int>, as an example. Prior to Scala 2.9, the compiler would represent
Option[java.lang.Integer] to the JVM, which would appear to naturally fall out of the requirement to use reference types as type parameters.
However, this led to significant problems, for example, implementing bridge methods for traits. The solution, for the time being, is that all primitive type parameters are represented as
Object to the JVM. The Scala compiler uses the
ScalaSignature annotation to determine what the Scala type needs to be in the cases where it matters.
Enter Jackson, which at its core is a Java library. The Scala module has informed Jackson that
Option is effectively a container type, but it relies on Java reflection to determined the contained type, and comes up with
Object. Jackson has rules for dealing with this situation, which dictate that the dynamic type of
Object values should be the closest natural Java type for the value:
java.lang.String for strings,
java.math.BigInteger for whole numbers, depending on what size the number fits into, and similarly
java.lang.BigDecimal for floating point values.
The Scala compiler doesn't know what evil has been done in Java-land. It "knows" the value is a primitive
int even if the JVM says
Object, so it attempts to cast the value to the relevant boxed type and unbox it. If the primitive type matches the type selected by Jackson, it works; otherwise the actual type protests such treatment in the form of a
The best solution for this problem would be to use Scala reflection to determine the Scala type, and tell Jackson which boxed type it should use. This solution is not without issues, for Scala reflection does not support anonymous or method-local types, and isn't a option at all for Scala 2.10, whose reflection API is experimental and is not thread-safe (and cannot be made so). This approach will not even be pursued until Scala 2.10 is no longer supported.
The second best solution would be to read the
@ScalaSignature annotation to determine the correct Scala type. This is a tricky proposition, as the API choices for this are limited (scalap exists but depends on the compiler, which is a large amount of code bloat for the task). For the intermediate term this is the best option available, but it is a significant task, and progress has been slow. It is unknown at this time when the work might be complete.
The current workaround for this use case is to add the
@JsonDeserialize annotation to the member being targeted. Specifically, this annotation has a set of parameters that can be used for different situations:
contentAsfor collections or map values
keyAsfor Map keys
Examples of how to use this annotation can be found in the tests directory.