Right now we are in play 2.3.8 and thinking to upgrade the play to the latest version 2.7. I have gone through all the migration documents and am aware of all the new features that are being added in each upgrade version. But still my BIG question to answer is, what we really gain upgrading our whole gaint application that was build on play 2.3.8 to 2.7? (Other than being up to date with the current version of play). Like, do we really gain performance? (Maybe or may not really), or any security gains or another such kind of benefits before we invest so much to upgrade to 2.7. There are vast amount of changes in play framework in 2.7 compared to 2.3.8 and it will be like rewriting the whole application again! Can anyone please guide through this?
@Sri I am not sure of performance gains and @marcospereira can speak to that. But I do see changes to be benefited from. We are in process of upgrading from 2.3.9 to 2.6.20.
1.) The Promise API was restrictive and has now been replaced with much richer CompletableFuture equivalent. This opened up our code to a lot of cool stuff supported by that API.
2.) Akka Streaming support - Creating complex processing graphs using Akka Streaming is one appealing feature. It is quite rich and if your usecase involves creating complex processing workflows with multiple stages, this can help you a lot.
There are multiple other enhancements (2.7 has more) that can be talked about, but the above are the ones that I found to be most useful and relevant for my usecases and are worth the effort.
I don’t know if you are using Scala or Java with Play, I use Java, so my comments will be coming from Java perspective.
Dependency injection (runtime) with Guice. Most Java developers would be familiar with DI using Spring or something else. DI is introduced in Play 2.4, and it made things feel “more natural” for Java developers that come from a Spring MVC background where DI is the norm. Granted you can use DI with 2.3, but having it out of box is really nice.
Akka HTTP as an alternative to Netty, with HTTP/2 support (although still experimental afaik).
Standardizing on Java 8’s new API. Although personally I have mixed feelings with Play’s Promise vs Java 8’s CompletionStage, but that’s the “future” of Java, and as a Java developer using Java with Play, this is a good thing in the big picture, I think.
I believe the version of Scala, SBT used by Play 2.7 would give you faster compile time. Not sure if that is a factor for you or not.
Improved Java API, such as you can write filters in Java starting 2.6 (or maybe 2.5, I can’t remember), so you are not forced to use Scala for these kind of things.
Various bug fixes and improvements that are not backported to 2.3, such as CORS.
As far as runtime performance is concerned, I am not sure if it got better or worse. I believe 2.4 or 2.5 is a release that contains performance improvements, especially for Java, but I have not heard or seen anything regarding performance in 2.6 and 2.7.
These are the main things that come to mind. Of course, there are other things such as updated library dependencies, etc… but those things you can probably do yourself anyway.
It wasn’t easy and it took more than just reading the migration pages. I basically took to reading the entire documentation, page by page.
And if I ran in to something that sounded like what I used, I checked to see how it was described, how the old implementation was and migrated that one thing.
And that way I moved through the documentation, altering my code as I went further, until the migration was finally done.
In my experience, the road from 2.3 to 2.4 (changing to use DI), and 2.4 to 2.5 (Promise to CompletionStage) have been the hardest. Later versions have not been so bad.
I was working on a java project in play framework version 2.4.2, now I want to upgrade it to version 2.8. Is it possible to directly upgrade from 2.4 to 2.8?
The short answer is no. If you go one minor version at a time, there are usually replacements for deprecated things. If you skip over versions, then your code will be straight up broken and there are no obvious replacements.