Unveiling Play 2.1 JSON API Bonus: JSON Inception with Scala 2.10 macros | Hacker News Reader

Unveiling Play 2.1 JSON API Bonus: JSON Inception with Scala 2.10 macros

mandubian.com

61 pointsmandubian32 comments

I've been using Jerkson (a layer on top of the excellent Jackson JSON processing library) to do case class marshalling/unmarshalling. It works quite well - in fact, nearly perfectly, but it still uses runtime type inspection to get things done. A nice, simplistic typesafe compiled parser would be ideal.

I'd love it if the play folks would break this out of the core library - it seems like this would be applicable to the whole Scala ecosystem, and not just Play.

Isn't Jerkson abandoned?

Not really alive at least and not compiled for Scala 2.10

There are a few github forks that have added a couple useful things. For my use case (converting case classes to/from JSON in scala 2.9.2) it works perfectly.

I've also written a Jackson plugin that knows how to marshal POSO classes - it's just an introspector that uses the scala convention instead of the JavaBeans convention. By and large it works well - perhaps I should put it up on github.

I love the idea! This makes a lot more sense than writing Formatters and repeating code everywhere. I'll play with this later today. Thanks!

You're welcome! The idea is to simplify writing basic Reads/Writes for simple Scala structures. In this way, you can focus on writing more complex JSON validation/transformation when you need it... For JSON coast-to-coast design that I introduced in previous article, this is quite useful!

If you have any question, don't hesitate to ask (or go to website and talk on disqus)...

This is awesome.

Something ironic about this though:

"As we are perfectionnist..."

Just an expression for transition, nothing more... why ironic?

because typo

oups :D Sorry: in French, there are 2 n in "perfectionniste" and in English, I never know when I must remove one "n" :D

should be corrected now ;)

Great work. This is a perfect application of Scala macros.

Nice work. Play 2 needs a LOT of work to get back to the simplicity and elegance of Play 1. This sort of effort really helps that.

To be fair, Play 2 is also vastly more powerful than Play 1 - the core concepts powering it are complex, but they lend flexibility that allow features like this to be added on top.

And Play2 core is composed of very robust components without any runtime enhancement, any magic. Using Scala power, we can build very clean tools, such as this one, without perverting typesafe/fully-compiled basements.

See this is something I've never understood. What is this obsession with type safety/everything compiled ?

Any possible benefits to the developer disappear in the face of a huge increase in complexity.

It depends on your mindset. I use both and love both but when it comes to massive changes on critical components in huge codebases give me static typing every time.

typesafety+compiled brings a robustness and sureness (and sometimes performance) that dynamic languages can't really provide. Dynamic languages are interesting in some domains also... I must admit I'm a big fan of static typed language since the beginning so I'm not really objective ;)

Making stronger apps?

Let's take the Play 1 vs Play 2 example:

How many times I got a 500 pages in the face due to a basic NullPointerException in Play 1 groovy templates...

In new play 2 templates, because they are type-safe, they guarantee that you will not have those basic errors.

Of-course, it doesn't guarantee everything, but it's way less error-prone. You actually CANNOT make this kind of NPE errors with type-safe scala code.

where in java you do something like:

user.address.town // oops I forgot to test if user.address is not null

in scala:

// user.address.town wouldn't work, because address is represented as an Option[Address]

user.address.map(_.town).getOrElse("")

I do understand your point as far as templates go. But they could have replaced the template engine or even improved on Japid.

It just seems that for the rest of the system there isn't any real benefit over Play1 if you are using Java as opposed to Scala.

...at the cost of a much higher learning curve.

There was a long email thread on the play framework, but as someone who is doing Play 2/Scala, they're nothing even close to the same framework, enough that calling it the same name is silly. Further, the deprecation of Play 1 does no favors, and I'm just hoping that as things go forward, a fork will emerge.

I'm also hoping that Play 2 will stop taking so ing long to compile longer projects. Is 2.1 going to make me not want to claw my eyes out?

Nice work on the new Json API, though.

What does Play 2 enable that was not possible or straightforward in Play 1?

(For Java, that is)

My two cents:

- non-blocking IO with the powerful iteratee concepts (a nice approach to play with streams (EventSource/WebSockets/*) which is not only an event-based approach like in NodeJS, but more a "reactive" approach)

- functional approach of things with Scala

- everything is much more type-safe (especially templates) which make apps stronger (not prone to simple error like NPE in templates) but also faster (templates are compiled)

The first two are obviously Scala only which is of no help to those with existing Java code bases. And for templates Japid is much, much faster than the Scala equivalent.

It does seem that real time data management is a good use case for Play2 but curious to know for typical web apps what benefits there would be.

Why would Japid be faster than Scala templates?

http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

This benchmark is based on Play 1 but you can see Japid is 4 - 5 times faster than the Scala template

play1.x with scala was quite experimental (play2 is really different and robustly designed) and those benchmarks always generate trolls... Anyway, I can't make people change their mind about those points even if I had numbers to show because everyone sees what he wants to see. This is just subjectivity ;)

Most of your points only apply to Scala.

Is there anything Play 2 Java can do that Play 1 Java + Japid template cannot do as well?

Seems like the move to Play 2 and Scala is more political than technical. The Play people formed an alliance with Typesafe, a Scala company, and thus decided to move away from Java and focus on Scala, abandoning their huge Java user base of Play 1.

Nope this is not what happened. Play team made the decision months before to start moving to Scala when experimenting the play-scala module of Play1.

This is a technical decision to build a web framework to the JVM. And even if the core is written in Scala, it doesn't mean you can't use it in Java. Give a try!

It also shows that the Scala feature set is growing (macros) and that the play group is not afraid of the awesome 210 [1] :-)

[1] http://www.scala-lang.org/node/16606

Could you please expand on why you felt v2 was a departure from Play v1 in terms of simplicity and elegance? Why do you think that is -- and why was that trade off not the right design decision (or was it?) in your point of view. And finally, why does this effort "help that."

I am genuinely curious about your conclusions, but I'm frustrated by not being able to guess how you got there as I'm not a java web developer.

Reply on news.ycombinator.com