What’s new in Play 2.4 | Hacker News Reader

What’s new in Play 2.4

playframework.com

59 pointsacjohnson5534 comments

This submission's title is horribly misleading because Play is not a Scala web framework. It's a web framework for Java and Scala.

As someone who's used Play heavily for the past couple of years, I'm very excited by this release, which is Play's best yet.

Do you use Play with Java?

I always thought Play looked incredible, but the focus on Scala puts me off. Every time I tried it, Java seemed like a second-class citizen in the Play world. I don't have anything against Scala, I'm just not really interested in learning it, especially if I all I want to do is use a web framework.

It seems that the Java support got much better since the initial release of play 2, and it is planned to get it on equal footing with version 3.0 which seems to be the next release after 2.5.

EDIT: never used the Java side myself, though. EDIT2: here is a nice comment on Java vs Scala: https://groups.google.com/forum/?nomobile=true#!searchin/pla...

I've used Play with Java, helped a customer (a big insurance company) move all their developments to Play Java.

It works fine. The only annoying thing is the asynchrone nature forces you to have abstract classes everywhere, but with Java 8 it's no longer a problem.

> the asynchrone nature forces you to have abstract classes everywhere

Could you elaborate?

Asynchronous code is often more performant, but requires you to supply a callback if you want to take further action after the async code completes. In Java, this typically means subclassing Callable or some other class and you end up with lots of anonymous subclasses, which can be quite verbose. Java 8 introduced new syntax by allowing lambdas which removed the verbosity. Play 2.4 uses Java 8 and some of its examples shrank quite a bit in terms of lines of code.

I think he/she meant anonymous classes, not abstract.

Akka uses callbacks to handle asynchronous behaviours, which means you need closures, and in Java <8, that means anonymous classes littering your code, which is a real PITA.

Oh yeah, that makes more sense.

The Java 8 syntax improvement is actually shown a bit down the page https://www.playframework.com/documentation/2.4.x/Highlights...

I find that while it works, it is a bit cumbersome. I also find this with Java API's in Akka, Spark, Kafka, etc. Having said that, I absolutely love Scala and I think you should learn it anyways (as with any language you can, even if it's only minimal).

Yes, I use Play exclusively with Java. I've never felt that Java is a second-class citizen with Play. All the features are supported from both languages and the core developers are very eager to ensure that you can work equally well with both languages.

I'm not entirely sure why Play has a reputation of being for Scala except that there are fewer web frameworks for Scala than Java, so Play is more popular among Scala developers. I think the other thing that confuses newcomers is that the templates are Twirl templates. They should probably have an extension like .twirl but unfortunately use the extension .scala.html even though you're really not writing Scala at all. You're writing Twirl which is it's own thing and doesn't take more than a few minutes to pick up. (The reason for the .scala.html is that templates get compiled to Scala, but you really don't have to know or care about that)

I have built a couple of apps running Play on Java and I like it. I still prefer Rails if the customer is starting on a clean slate but Play Java has worked out pretty well.

Thanks, we updated the title to that of the article.

Great point, my bad!

I've been using Play for about 2+ years with Scala. I think it's a cool framework and has removed most of complexity that you see with other JVM-Web frameworks. There are few things that are still missing, like up-to-date docs. and bundled ORM. The plugin community needs to be better organized so it has potential to become a gem like community.

> up-to-date docs

Which parts are out-of-date?

> and bundled ORM

Didn't they just go the other way, de-bundling all persistence APIs/libs?

What's wrong with just picking the one that's right for your use-case and using just that?

I still miss the simplicity of Play 1.x... also does Play 2 have a admin CRUD module yet?

Agreed - I feel like the simplicity was lost in order to make the framework more scalable, when 95% of sites don't need the added scalability it provides.

Play 1's code generation / scaffolding for CRUD apps was nice. It would be a cool feature to add to Play 2.

I really find Play 2 to be an enormous improvement over Play 1 though. As just one example, deploying your app is so much easier in Play 2. Play 1 expected you to install the framework on your production machines. Play 2 has built-in support for building deb/rpm packages, docker containers, zip archives, etc. which makes deploying so much easier.

Yes, such a big improvement. With SBT's 'sbt docker:stage' command it's pretty much trivial to get a Play app running on a cloud provider that supports docker.

I used play2crud once. It was a good plugin : https://github.com/hakandilek/play2-crud

Glad to see they are requiring Java 8. Should make writing play applications in Java a lot nicer.

Interesting that Java 8 is a strict requirement. I'm curious what version of Java is most common in enterprise these days?

Can someone compare this framework to Django or Rails? Java was my first language and I sorely miss a lot of aspects in it. Would be interested to know about the learning curve, performance, and ORM.

And how does it compare to DropWizard? I'm porting a plugin from Atlassian Confluence to make it a standalone app, and I'm leaning for DropWizard because I can reuse and share the common code made of Jersey REST resouces and synchronous calls.

Both Play and DropWizard seem to have the same goal, Play being more integrated and scalable, DropWizard more respectful of existing Java frameworks.

I've recently tried to use play with scala on a new project after having had a very pleasant first experience with play/java, but found the overall experience much much less convincing. IDEs often don't work well with the language, and some key parts of the framework such as ORM seem still a work in progress.

Anyone else had the same feeling here ? I came to the conclusion that play should advocate the use of java as the preferred language if they want to grow their user base even more.

Great release, I especially like the built in reverse router for subprojects and the better dependency injection aproach.

Page layout doesnt look right on my android 5.1 tablet chrome even after I requested the desktop version.

Great release, kudos to the team.

Dependency injection was one of the barrier of entry for me. This is a huge milestone.

FYI, this URL is anchored towards the bottom of the page. Scroll up to see everything.

Standardized dependency injection is great news! The Play application I work on has a home-grown dependency injection system that leaves a lot to be desired. It will be great to see a more standard way of doing this.

I have seen many projects use scala-guice [1][2]. If all I have to do is build a module [3] and @Inject[4] in to the top of my controller, I struggle to see the benefits of Play supporting it directly.

1 - https://github.com/codingwell/scala-guice 2 - https://github.com/mohiva/play-silhouette-seed 3 - https://github.com/mohiva/play-silhouette-seed/blob/master/a... 4 - https://github.com/mohiva/play-silhouette-seed/blob/master/a...

The big difference with 2.4 is that Play now uses DI internally. So if you want to replace some Play component with your own version of that component, you can do that. With 2.3 you could use DI with your own app, but couldn't with any Play-provided components.

Reply on news.ycombinator.com