[yareally]

With Play 2.0 in Java, there's more verbosity (though nothing like any J2EE framework) in using Java and lack of syntactical sugar features as well as functional programming features (which are widely used in parts like JSON for Play). Also, you don't get the benefits of such things as optional parameters in Java.

Don't get me wrong, the Java version of it is going to be better than any other Java web framework you ever encountered most likely (especially if everything else one tried was based in part on J2EE/JSP since Play has none of those and no XML bs config). However, you do lose some of the Scala niceties when going that route. You still can still call to Scala bits of the API in Java and templates themselves are all Scala (Lift templates), but it's still not quite the same.

If using something like Intellij, you can still mix and match bits of Scala and Java in the same project (but not within the same class file) without too much trouble. Not sure how the official Scala IDE that TypeSafe maintains handles that offhand.

[vassvdm]

I agree with the above. As a Java and Scala programmer I've tried both and Play! 2 Scala is a joy to use if you're fond of idiomatic Scala and functional programmming.

I use Eclipse with the Scala IDE plugin and although I write all of my code in Scala, I do have a couple of dependencies to Java libraries (the interop works perfectly, but of course you should be careful when mixing immutable code with potential sources of mutability). The Intellij plugin is probably still the more stable of the two, but as mentioned by yareally the Scala IDE is the officially maintained one so you can expect new features to come to Eclipse before Intellij.

[haimez]

Excellent summary. A lot of the API's are definitely built scala-first, then adapted for Java. Usually this isn't too bad, but it can cause some headaches around things like the logger interfaces, etc.

We run a fairly complex java system in the same process as play (similar to an in-process database) for performance reasons, so given the amount of code already in java and not having the time to learn scala, java interop, AND build in the web bindings, we went the Java route.

It's definitely easier to use than something like Spring if you're approaching both for the first time.

[erwanl]

It's not that it's "Scala adapted to Java", but more like a choice to do async and functional programming even in Java. That makes stuff a bit verbose sometimes because to pass a function you have to pass an anonymous class.

That will become better with Java 8 and lambdas without having to break compatibility with older Java versions (they will still use anonymous classes).

[eropple]

> Don't get me wrong, the Java version of it is going to be better than any other Java web framework you ever encountered most likely (especially if everything else one tried was based in part on J2EE/JSP since Play has none of those and no XML bs config).

It doesn't sound like you're really familiar with other Java frameworks. While I'm not really a fan of it, Ninja (as just one example) has none of that, and also doesn't have the torture chamber that is Play's (non-standard, custom, even more undocumented) flavor of sbt--easily the worst not-Maven Maven tool I have had the displeasure of working with.

I want to like Play because I love a ton of what they do, but just having to deal with sbt and the non-standard, doesn't-play-nice build system that they enforce has driven me away from it.

[eeperson]

You can also run Play projects with vanilla SBT. That's what I usually do. Then you don't have to worry about the unusual stuff that Play does.

[eropple]

Honestly I'd like to run them with vanilla Maven. There's play2-maven-plugin that's trying to get there and that'd be a great thing, I wish them well.

[taeric]

When considering the verbosity, are you comparing to the modern frameworks such as Jersey?

[yareally]

Never used Jersey so cannot comment on ease of use at the code level. It may be similar, but it'll likely not have other nice features that Play has that sets it apart from other Java Frameworks.

I was comparing against any Java Framework that depends on J2EE and JSP though as that comes with an excessive amount of baggage that's really hard to get rid of totally (like excessive use of XML tooling/configuration). If one's reason for never touching Java on the web is because of the XML nightmare it generally brings, then Play is the framework one has been searching for. There's no use of XML anywhere that is required and templating/views are similar to what one would do in any scripting language since they're really Scala (Lift) templates and not kludgy JSP that reminds me of ColdFusion.

Also, being built on Scala shapes Play 2.0 in ways that other Java Frameworks are not by design, since Scala is generally against excessive verbosity and it's a Java habit that dies hard for some even when trying to avoid it.

I'll admit I'm biased against excessive XML tooling and configuration, since I come from a PHP & Python background in web development, but I dislike all that boilerplate. I realize it's sort of a common part of almost everything Java, but it's also why I stay away from Java on the web as much as possible.

Edit: Jersey does make use of JSP[1] (Java Server Pages). Some may not find that to be bad thing if they're used to it from prior experience, but I would avoid it personally. If coming from a dynamic programming background on the web (Node.js, PHP, Python, Ruby, etc), JSP is not a fun time.

[1] https://github.com/jersey/jersey/tree/2.3/examples/bookstore...

[taeric]

Jersey is really easy to use as strictly a REST backend. I fully grant that Java is, in general, more verbose than Scala. Just curious if you were comparing this based solely on past experiences. (That is, when making a "service" with Jersey, there is surprisingly little boilerplate. There is the verbosity of Java, but pretty much none of the other.)

And, really, it mainly depends on how you want to structure your application. At face value, an angularjs/whatever frontend that calls to whatever REST implementation you can bring to works quite well.

Regarding JSP, yeah, planning on avoiding that as much as possible, though, for a quick "put a dummy string into a page," I can't say it is that terrible. (I fully grant that is a very slippery slope.

[russ519]

Awesome, thanks for the info!

[yareally]

No problem. I was stuck to mostly using the Java side of it for a project that Java was the requirement. It was a university requirement, as I could not convince my group into experimenting with Scala for the entire project. They were mostly worried they would not learn it fast enough to have us finish the project on time and I agreed, since it was a valid concern.

I was worried how it would fair after trying Play 2.0 in Scala previously for my own work. However, it was not anywhere as bad as I thought, but I was a bit envious of not being able to use some of the features of the Scala side I had used previously.