Deserialize to Scala collection for values of unknown type

[vdichev]

It would be great to be able to deserialize to a Scala collection instead of Java collections when you don't know what your input would be. There are use cases when you know you could have a Map just as well as a List, so your options are either to use parse[JValue] or parse[Any]. The problem is that these both get back java collections, and you can't pattern match them or flatMap them, etc.

Of course, there is the workaround to convert from JValues (or Java collections) to scala collections every time, but you lose some performance.

[sroebuck]

I guess the issue here is that Jerkson is built on top of the performance and reliability of Jackson which is a Java JSON parser. If Jerkson is going to return Scala collections by default then it either auto-converts the result, which hits the performance issues you suggest, or does the parsing itself which sidesteps the whole reason for building it on Jackson.

If you use the Twitter JSON library which is a branch of scala-json based on the JSON example in Odersky's Scala book, you can enter:

scala> com.twitter.json.parse("""[null,{"a":"map", "with":["a","list"]}]""")

and you get:

Any = List(null, Map(a -> map, with -> List(a, list)))

I suspect that this isn't as performant as Jerkson's Jackson backend, but it works.

I have been flitting between Scala JSON libraries of late and found myself trying Jerkson because it looked simple and I knew Jackson was fast. I also noted in some discussions that there seemed to be a move in Twitter to use Jerkson and I was concerned that Twitter's JSON libraries do not appear to be actively maintained.

However, I keep falling back on the Twitter version the latest version of which is:

    "com.twitter" % "json" % "2.1.4"

in sbt parlance.

[vdichev]

Yeah, I liked this in Twitter's library, but for various reasons I can't use it. Let's just say it's suitable code to put in a book, not in production.

So back to Jerkson- judging by the deserializers code, it does seem that it doesn't create intermediate Java collections. It still relies on Jackson to parse the string into tokens, it's just using factories from scala.collection.generic.

But let's forget about performance. It's just not very consistent. You're able to get back:

• a Scala collection if you know what it is
• a Java collection if you know what it is
• a Java collection if you don't

You just can't get back an arbitrary Scala collection. I think the user should have this choice.

[azinman]

I disagree. To me the entire point of having a scala interface is that I will be dealing with collections. The fact that it's using Jackson behind-the-scenes isn't as important as just having a performant scala json library with a sane API. I was using the Twitter but it's just too slow (but ideal API).

What's strange is that I can do Json.parse[Map[String, Any]] but any arrays/maps inside the main return Scala Map will be Java maps.

I'm writing some recursive conversion code right now on my fork (along with Joda DateTime serialization) to overcome this limitation. I'm afraid there will be some performance hit. It would be far greater if either through integration/modification with Jackson or otherwise we could have Scala all the way through.