
What’s new in Play 2.4 - acjohnson55
https://www.playframework.com/documentation/2.4.x/Highlights24
======
benmccann
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.

~~~
rmsaksida
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.

~~~
eloisant
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.

~~~
robmcm
> the asynchrone nature forces you to have abstract classes everywhere

Could you elaborate?

~~~
zzalpha
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.

~~~
robmcm
Oh yeah, that makes more sense.

------
dk8996
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.

~~~
justthistime_
> 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?

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

~~~
benmccann
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.

~~~
sbilstein
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.

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

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

------
dopeboy
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.

~~~
tajen
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.

------
bsaul
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.

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

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

------
goralph
Great release, kudos to the team.

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

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

------
benburton
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.

~~~
kodablah
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](https://github.com/codingwell/scala-guice) 2 -
[https://github.com/mohiva/play-silhouette-
seed](https://github.com/mohiva/play-silhouette-seed) 3 -
[https://github.com/mohiva/play-silhouette-
seed/blob/master/a...](https://github.com/mohiva/play-silhouette-
seed/blob/master/app/modules/SilhouetteModule.scala) 4 -
[https://github.com/mohiva/play-silhouette-
seed/blob/master/a...](https://github.com/mohiva/play-silhouette-
seed/blob/master/app/controllers/ApplicationController.scala)

~~~
benmccann
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.

