Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

FAQ

Christopher Currie edited this page · 8 revisions
Clone this wiki locally

How do I support Scala Enumeration

Enumerations

Deserializing Option[Int] and other primitive challenges

TL;DR: Use @JsonDeserialize(contentAs = classOf[java.lang.Integer]) on the offending member.

What is happening, and why

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[Int] as 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.lang.Integer, java.lang.Long, or java.math.BigInteger for whole numbers, depending on what size the number fits into, and similarly java.lang.Float, java.lang.Double, or 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 ClassCastException.

Possible solutions

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.

Current workarounds

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:

  • contentAs for collections or map values
  • keyAs for Map keys

Examples of how to use this annotation can be found in the tests directory.

Something went wrong with that request. Please try again.