Support Scala case classes

[cowtowncoder]

(copied from [http://jira.codehaus.org/browse/JACKSON-304] -- see details)

(by James Strachan, Greg Zoller)

It doesn't feel very dry doing Scala with Jackson...

@BeanInfo class Position {
@BeanProperty
var x: Double = _
@BeanProperty
var y: Double = _

override def toString = "Position(" + x + "," + y + ")"
}

when it would be much nicer to be able to do

case class Position(x: Double, y: Double)

The main issue is that this class is immutable and that (ii) there are no fields/setters to call when deserializing, just a constructor.

Though when serializing the fields can be used.

Unfortunately Scala doesn't yet seem to support an easy way to iterate through the product field names & constructor argument names AFAIK so until Scala offers more reflection help this might be tricky...

[advorkovyy]

try scalabeans. it has also bean builder, you provide it with property values you have and it figures how to create new bean instance with them: either via constructor args or by assigning property values or by combination of both.

[christophercurrie]

Thanks for the tip; I'd been exploring the ScalaSigParser in scalap, but the API in scalabeans looks much friendlier

[cowtowncoder]

What do auto-generated properties look like? Since it is possible to figure out which classes are case classes, it should be possible to construct scala-specific AnnotationIntrospector to change definition of how property names are introspected for fields. This also applies to implicit get/set methods (set ones end with '='?).

[christophercurrie]

That's the approach I'd tried to take with scalap, but the API wasn't nearly as convenient. I've managed to get a very simple test case working with just constructor arguments. I'm going to take a stab at extending it for read/write properties outside the constructor before committing.

[advorkovyy]

Properties have auto-generated getter with the same name as property and setter with "_$eq" suffix. Setters are generated only for mutable properties (var). Variables (val/var) are in the same symbol space as methods in Scala (in contrast with Java), ie there cannot be both variable and method with the same name. When using Java reflection method can be distinguished from val by looking at the presence of private field with the same name.

There are some other interesting situations like "synthetic" properties (having explicit getter/setter in Scala code), constructor parameters, properties derived from superclasses. They might have slight variations of described pattern.

Another peculiarity is that since Scala 2.9 in some situations Scala types are seen from Java reflection as just Object. For example, Option[Int] becomes Option<Object> in Java reflection. So, using ScalaSig is inevitable to get the right property type.

This all applies to all Scala classes, of course, not only to case classes.