36

I am thinking about migrating to play 2.0 after play 1.2. One thing that bothers me is that people say Scala is more "preferred" for a play 2.0 application. I know the differences over 1.2 and 2.0, but I'm unsure if there are differences between Play 2.0 with Java and Play 2.0 with Scala

So there are questions in my mind:

  • Is there anything that I cannot do with java over scala in a Play 2.0 application?
  • What advantages do I have if I start to learn and use scala in a play 2.0 application?
om-nom-nom
  • 62,329
  • 13
  • 183
  • 228
dreampowder
  • 1,644
  • 3
  • 25
  • 41

4 Answers4

25

I just finished a prototype using Play 2.0 with Java and now am considering to learn Scala just so I can switch to it for further development.

It's not just the usual Java vs. Scala discussion - the problem as I see it with the Play framework is that it forces Scala idioms onto Java. An example from the documentation about calling multiple web services:

public static Result feedComments(String feedUrl) {
  return async(
    WS.url(feedUrl).get().flatMap(
      new Function<WS.Response, Promise<Result>>() {
        public Promise<Result> apply(WS.Response response) {
          return WS.url(response.asJson().findPath("commentsUrl").get().map(
            new Function<WS.Response, Result>() {
              public Result apply(WS.Response response) {
                return ok("Number of comments: " + response.asJson().findPath("count"));
              }
            }
          );
        }
      }
    )
  );
}

It works but doesn't look like conventional Java. Those parentheses look really scary. Even Eclipse gets confused and never knows what generics I need or want to use - I always have to choose them manually.

Also note that in the documentation they made this look pretty by removing @Override annotations, using just two spaces for indentation and overall choosing a very simple example without validation or error recovery so they don't use too many lines. I'm not even sure you could configure a code formatter to output it like this without messing up other code completely.

In practice I ended up with an unreadable block of a horrible Java-Scala-abomination just for getting some data from another service.

Unfortunately I can't find any example of combining responses in Scala. At least calling single web services in Scala looks much shorter and easier to read.

kapex
  • 28,903
  • 6
  • 107
  • 121
12

AFAIK, it is better to go with Scala, because it offers more functionnality.

For instance (correct me if I'm wrong), you can directly using the Iteratees with Scala (aka reactive programming), but I don't know how to achieve that with Java.

Also, the Java API of Play is an upper layer in the Play architecture, the core is written with Scala; so if you want to lean what's happening inside, go with Scala.

And also note that you can mix Java and Scala in the same Play project, so you can move smoothly to Scala.

ndeverge
  • 21,378
  • 4
  • 56
  • 85
  • Iteratees look quite intresting and scala code looks really compact – dreampowder Sep 23 '12 at 12:28
  • For sure, Scala is less verbose than Java :-) You can also take a look at this: http://stackoverflow.com/questions/727078/whats-so-great-about-scala – ndeverge Sep 23 '12 at 12:30
  • 3
    @dreampowder De facto, AFAIK, iteratees is probably only one missing feature in Java version, other elements are very comparable in both languages. So if you're more comfortable with Java you can stay with that and use Scala only for missing part. If you have no preferences... you need to check yourself which language is better for you. – biesior Sep 23 '12 at 12:51
  • 2
    yep, you can mix Java and Scala in the same Play project, so you can move smoothly to Scala – ndeverge Sep 23 '12 at 12:54
  • @nico_ekito sounds like a good plan, i can develop with java while i can add scala code into the project as i learn scala.. – dreampowder Sep 23 '12 at 18:27
4

I was new to Play and just wrote a small-mid sized Project with the Java side of it.

It works and is powerful, but a lot of Features just seem to be very Scala centric and the Java support is sub-par. The Java API Doc is virtually non existent, which takes away some comfort in the IDE (IntelliJ - I recommend it). The integration in the Java world is not very "natural" (SBT..), It does not build as a war or maven module (but there seem to be plugins to do this). You kind of loose the benefits of the existing Java tooling.

The concepts which differentiate Play from the other Frameworks almost all seem to be scala native and Java second.

I stumbled onto some bugs and quirks and I always would end up in Scala code I had to read and understand to fix or work around it. (Actions, RequestBody stuff, Async, routes, template implicits and so on)

So the Java side of things just feels very second tier to me, although they are clearly making an effort for them to be equally good.

Now, after the Project, I would say it is very usable and would even use it again (in Java).

sleeplessnerd
  • 21,853
  • 1
  • 25
  • 29
3

What advantages do I have if I start to learn and use scala in a play 2.0 application?

As djangofan commented, when you google for Play help, you get examples in Scala.

Is there anything that I cannot do with java over scala in a Play 2.0 application?

However, I haven't yet (still a beginner) found an equivalent of Ebean for Scala. The Scala examples I've found all use direct SQL for persistence. Where's the database abastraction?

Since I haven't found a database abstraction for Play with Scala, I'm continuing with Java...

GreenAsJade
  • 14,459
  • 11
  • 63
  • 98
  • 1
    i am on the same path too. still going from java. Also they have improved java documentation quite much since i've asked this question – dreampowder Dec 30 '13 at 09:48
  • The use of direct SQL is an advantage if you favor performance over convenience. –  Oct 06 '14 at 23:16
  • 1
    That's like saying the use of assembler is an advantage over C# if you favour performance over convenience... sure there's a time and a place, but not in general application coding. – GreenAsJade Oct 06 '14 at 23:36
  • @GreenAsJade, the thing is that SQL is already an abstraction as C# or Java are. ORMs are another level of abstraction over SQL. Look at SQLite or Caché Intersystems, they both permits to see what goes under the hoods. Your SQL is translated into instructions to be processed by the underlying engine. What is a pity is that a lot of developers consider SQL as the assembly of databases. SQL is a first class citizen and ORMs are a convenience. In fact, ORMs could be compared to EGL. They both abstract another language behind and shadow some flexibility. – programaths Jun 14 '15 at 08:11