Can we consider that Play Framework is a stable tool in development environment ?

[Aurélien Panhaleux]

I'm lead developer of a small French startup who's doing e-commerce mainly in boat maintenance.
I started using Play 2 years ago, at the time we were using Play 2.1.5, since then, we manage to update to 2.3.10, which already is a good jump ahead since we got more 250 java files and 250 scala files to handle.
My concern today is about Play framework stability in development environment, for medium project like this, and what I have observed during this 2 years but haven't really shared :

- Sometimes when compiling code I get a NullPointerException on a variable that has absolutely no reason to throw one, the only solution I have is to activator clear and then recompiling everything to go, this takes me at least 80 seconds more. It happens more often when I do huge refactoring operations on class names / routes.

- Binding errors on Form objects, that triggers error on form submitting, happens erratically and need a full recompilation to be corrected.

- Errors messages / traces related to routes files compilation or scala template files are really hard to understand and it is required to go deep into the stack trace to have a bit of a clue to what the real problem is.

- With a project including more than 500 files to compile, the compilation process becomes really heavy and slows down a lot the development process when I need to simply observe the result of what I am coding.

More generally, my observations is that I spend a lot of time, maybe 20% of my time recompiling everything because some cache / binding problem / obscure reason is blocking me in my work process, and often it really get on my nerves when I do the comparison to the simplicity and lightness of an interpreted language. I don't know if this is better in play recent versions, I understand that I'm working on a relatively old one. Moreover, maybe the problems I put forth aren't Play's concern directly or more a jvm problem or something else.

What do you think ?

[Christian Schmitt]

Actually we have some pretty big play apps in production (Scala) and I only get NullPointerException in the compile process when I try to compile and run a SBT Task from my IDE. However that won't happen often and then I don't need to sbt clean. I can just recompile again.

80 seconds compile time is also not really much.

- Since I use Scala I can't say anything about the Java Forms behavior, but actually never had that error.

- If you aren't happy about the routes file you could try out Play's SIRD Router for Java/Scala that is there since Play 2.5: 

https://www.playframework.com/documentation/2.5.x/ScalaSirdRouter

https://www.playframework.com/documentation/2.5.x/JavaRoutingDsl

Actually these are way more "typesafe" and don't generate stuff.

- 500 files is "nothing". really. 

Actually handle "caching" sane is mostly a "fault" of the developer itself and it's really really hard to do it correctly. 

Actually we started with Play 2.1, too. But migrated all our Apps to 2.5 and since Play doesn't "need" activator things got way better and more modern compiler/sbt also making things more smooth.

The transition process could be really hard depending on what external libraries you are using. We only had problems with securesocial on one application that didn't get updated, but it could be a real pain if you use Scala 2.10 libs that don't exists for 2.11 or that using Play internals that won't exists anymore. The best thing is incoporating these things for a while and switch to new stuff as soon as you are upgraded everything.

Using interpreted languages could sometimes make your initial process faster, but refactoring stuff could be more than a pain.

Before Play! we used Django (which is great) but didn't fitted our work process and made some things really hard. (iterating over bigger lists/maps and sharing that in concurrent processes is considered really really hard)

[Igmar Palsenberg]

 

I'm lead developer of a small French startup who's doing e-commerce mainly in boat maintenance.
I started using Play 2 years ago, at the time we were using Play 2.1.5, since then, we manage to update to 2.3.10, which already is a good jump ahead since we got more 250 java files and 250 scala files to handle.
My concern today is about Play framework stability in development environment, for medium project like this, and what I have observed during this 2 years but haven't really shared :

- Sometimes when compiling code I get a NullPointerException on a variable that has absolutely no reason to throw one, the only solution I have is to activator clear and then recompiling everything to go, this takes me at least 80 seconds more. It happens more often when I do huge refactoring operations on class names / routes.

We're on 2.5.4, and I've never seen this. Only a major upgrade (2.3 -> 2.4 -> 2.5) require a clean cleanFiles

- Binding errors on Form objects, that triggers error on form submitting, happens erratically and need a full recompilation to be corrected.

- Errors messages / traces related to routes files compilation or scala template files are really hard to understand and it is required to go deep into the stack trace to have a bit of a clue to what the real problem is.

- With a project including more than 500 files to compile, the compilation process becomes really heavy and slows down a lot the development process when I need to simply observe the result of what I am coding.

Also never seen this. What I've seen is that compilation sometimes hangs when a debugger is attached.

 

More generally, my observations is that I spend a lot of time, maybe 20% of my time recompiling everything because some cache / binding problem / obscure reason is blocking me in my work process, and often it really get on my nerves when I do the comparison to the simplicity and lightness of an interpreted language. I don't know if this is better in play recent versions, I understand that I'm working on a relatively old one. Moreover, maybe the problems I put forth aren't Play's concern directly or more a jvm problem or something else.

What do you think ?

Time to upgrade.

Igmar 

[Aurélien Panhaleux]

You're right I launch the application with my IDE, maybe I should change that. 

What do you mean by "since Play doesn't "need" activator", it does require it since 2.3 right ?

[Aurélien Panhaleux]

Thanks for your advice !

[Igmar Palsenberg]

 

You're right I launch the application with my IDE, maybe I should change that. 

What do you mean by "since Play doesn't "need" activator", it does require it since 2.3 right ?

activator is basically just a sbt wrapper. It does "need" SBT, at least, if you're doing development like the way Play developers intended it (not embedding play).

Igmar

[Greg Methvin]

Activator is only really useful when you're getting started since it allows you to create new projects from templates. It's essentially an extension of what the old "play" executable did. Once your project is set up you just need to use SBT. We are actually looking to phase out activator soon and just allow starter templates to be downloaded from the web.

I would say to get the full dev experience you need sbt, especially since a lot of the functionality (dev reloading, routes compiler, twirl template engine, etc.) is implemented as SBT plugins. But if you don't need any of those things you could use the embedded Play with maven or gradle.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/3ab91896-ee6b-4de6-bc09-fb00026da49d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

[Naftoli Gugenheim]

On Fri, Jul 1, 2016, 1:55 PM Greg Methvin <gr...@lightbend.com> wrote:

Activator is only really useful when you're getting started since it allows you to create new projects from templates. It's essentially an extension of what the old "play" executable did. Once your project is set up you just need to use SBT. We are actually looking to phase out activator soon and just allow starter templates to be downloaded from the web.

FWIW Intellij allows to create a new project by choosing a template from the Activator registry

Also I seem to recall talk recently about a similar but more general thing for sbt

Perhaps scaladex could help somehow

Also Activator's mini-IDE is not a small thing for getting people started (at least of it were more stable than last I tried)

I would say to get the full dev experience you need sbt, especially since a lot of the functionality (dev reloading, routes compiler, twirl template engine, etc.) is implemented as SBT plugins. But if you don't need any of those things you could use the embedded Play with maven or gradle.

On Fri, Jul 1, 2016 at 3:30 AM, Igmar Palsenberg <ig...@palsenberg.com> wrote:

 

You're right I launch the application with my IDE, maybe I should change that. 

What do you mean by "since Play doesn't "need" activator", it does require it since 2.3 right ?

activator is basically just a sbt wrapper. It does "need" SBT, at least, if you're doing development like the way Play developers intended it (not embedding play).

Igmar

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/3ab91896-ee6b-4de6-bc09-fb00026da49d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11HzJEkUjgSoRya%2B3Au2geToVMc3Go-iBqv8QcXH9ebxySQ%40mail.gmail.com.

[Aurélien Panhaleux]

Well I just started to make some tests with sbt only, so not compiling from IDE, because intempestive NPE started to happen a lot (for no reason like I mentioned in my first post, knowing that re-compiling the entire project just make the error disappear).
Problem is that I'm still getting the same Null Pointers problems =)

I don't really know what to think of all this...

Maybe I should just upgrade (still running on 2.3), but 2.3 shouldn't be stable already ?

[Thibault Meyer]

In our startup, we are using Play since 2 years without any major issues.

Con :

- New version break old API (2.3 to 2.4 and 2.4 to 2.5 force us to rewrite code, and some deprecated method dont have new alternative or, worth, alternative dont work even if we follow line per line the documentation)

- Before 2.5, Java version of Play was just like a retard dumb horse compared to Scala version (but it's more easy to find Java developer than Scala)

- Ebean version is tooooooo old and need manual upgrade (https://groups.google.com/forum/#!topic/play-framework/yGo7Dz3ozik)

- Used with IntelliJ, it just a nightmare, compilation alwayz fail because this %#12%£$ IDE lock file every 2 seconds

Pro : 

- Java !  (typed language)

- Fast execution

- Asynchronous

- Easy to learn

- You can create project prototype within few days / weeks

- Json / REST API

Le jeudi 30 juin 2016 11:27:58 UTC+2, Aurélien Panhaleux a écrit :

[Aurélien Panhaleux]

Thanks for your share.

"Before 2.5, Java version of Play was just like a retard dumb horse compared to Scala version (but it's more easy to find Java developer than Scala)"

You just tickled my curiosity, what do you mean exactly by "retard dumb horse" ?

Le jeudi 30 juin 2016 11:27:58 UTC+2, Aurélien Panhaleux a écrit :

[Thibault Meyer]

When you want to advanced framework usage like filter, action, ... it was difficult to implement it.  Same think for binder (PathBindable, QueryStringBindable) who as mose easy to implement directly in Scala than Java.  Other ""issue"" is than many class on Java are immutable and not in Scala version. Or annotation/action on Java don't have access to binded URL value (ie: if you have the url /hello/:word    controllers.Demo.sayHello(word: String), the annotation/action can't access the var "word" without handmade parsing of the http query.

[Greg Methvin]

Since there is obviously a lot of interest in this thread, I want to ask a question: how can we improve some of the "cons" of Play in Play 3.0?

Changing Java actions to work more like they do in Scala (without annotations) is definitely on the table, and that is also where a lot of the mutable state is in the Java API. I'm not sure what I would do with filters.

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/d716f689-679f-4fb0-b69e-590d477e1de9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[virtualeyes]

While I have no evidence that Play 2.5.x is the culprit here, incremental builds have gotten so slow, it's incredible -- literally upwards of 5 seconds in `run` mode when adding a simple println(...) within body of a method.

Could be many factors involved:
sbt 0.13.8 to 0.13.11
enabling withNameHashing sbt incremental compileation flag (had it disabled since its introduction)
using compile time DI (MacWire, macro based)
large refactoring of our pre-2.5 code base

At any rate, if Play is indeed the source of incremental build slow down, please, add it to the 3.0 TODO list ;-)

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/d716f689-679f-4fb0-b69e-590d477e1de9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Slinn]

Greg,

How about introducing stronger type safety for Play Framework 3.0? For example, Results.Redirect accepts a String, but does not have an overloaded version that accepts a URL. Strings are used extensively throughout the API, but there are many well-known types that, if used, would provide much better type safety.

In addition, some of those well-known types could be enriched. This is of course easy to do in Scala. For example, here is a RichURL I whomped up a few minutes ago, which inspired this posting:

import java.net.URL

implicit class RichURL(url: URL) {
  def setPath(newPath: String): URL =
    new URL(url.getProtocol, url.getHost, url.getPort, newPath)

  def setProtocol(newProtocol: String): URL =
    new URL(newProtocol, url.getHost, url.getPort, url.getFile)

  /** @param newQuery will be URL encoded */
  def setQuery(newQuery: String): URL = {
    import java.net.URLEncoder.encode
    import java.nio.charset.StandardCharsets.UTF_8

    val newFile = url.getPath + (if (newQuery.trim.isEmpty) "" else "?" + encode(newQuery.trim, UTF_8.toString))
    new URL(url.getProtocol, url.getHost, url.getPort, newFile)
  }
}

I think RichURL or something similar, and other enriched types should be part of the Play Framework for Scala code base. I believe that there are dozens of method signatures that should be modified to accept strong types, instead of Stringified versions. Play for Java would also benefit from enhanced type safety.

Mike

[Greg Methvin]

Hi Mike,

We definitely want to do something like this for 3.0 (maybe with an optional API in 2.6). But most likely we want to use a library like scala-uri or some other type instead of basing it on the broken java.net.URL.

Greg

--

You received this message because you are subscribed to the Google Groups "Play Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/6dbd8bf4-6a43-460a-8033-1a2068e4d2c9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Slinn]

Excellent!

To do a proper job, there would be a lot of breaking changes. But that
would be fine for 3.0.

2.6 could introduce already-deprecated overloaded versions, for
compatibility, and the stringified versions would be removed in 3.0 for
type safety.

Mike

[Michael Slinn]

BTW, the Play Framework 3.0 Roadmap only says "Headers become strongly typed". It does not mention making the rest of the API strongly typed. The 2.6 description also only mentions typesafe headers, nothing more.

The Roadmap is an important document. If Play Framework is going to become much more typesafe in general, this change and its ramifications should be communicated. Details such as the classes and packages likely to be impacted by this change should be mentioned. Options that are being considered, such as the possibility of using scala-uri, such be kept up-to-date as discussions regarding future versions transpire. In the past this type of planning and communication was largely not evident, and much pain has been felt by users as a result.

Mike

[Greg Methvin]

Hi Mike,

The roadmap for 3.0 isn't quite done yet since we are focused on the upcoming 2.6 release right now. We will update when we actually have time to plan out these features in more detail, likely around the end of this year or early next year. This is a great time to provide feedback.

I believe many other parts of the API could be more strongly typed, e.g. we could have types for HTTP method, path, version, etc., but we haven't made decisions about how we are doing that. In my opinion type safe headers provide much more value than making individual named properties type safe, so we are focusing on that first.

Also, yes, we will break some API compatibility, but we want to make sure migration is not too difficult either. So I'd prefer to make changes that can be migrated to in 2.x in some way before we remove things completely.

Greg

--

You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/bc4b7e39-48aa-4c6e-88d5-2a6ba6553979%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Slinn]

Roadmaps are most useful when they are forward looking. I understand that I am proposing a change to how this project has been managed to date.

Just ask anyone who had a Play Framework 1.x project about how they were impacted by the lack of a roadmap. Or a 2.0.x user. Or a 2.1.x user... etc.

Mike
 

[Greg Methvin]

I'm not sure exactly what you mean, but I would certainly agree if you said the roadmap in the past could have done a better job outlining what is to come in the next release. And this is even more important in 3.0 since we plan to make more breaking changes than usual.

Play 3.0 is roughly a year and half away, and we are still in the planning phases, but we've released the roadmap so the community can start contributing. It's not meant to be treated as a complete and comprehensive plan, at least not at this point. But by the time 2.6 is out I'm sure it will be much more complete and detailed than our previous roadmaps.

If a particular feature is not in there already, that usually means it's not happening or we haven't considered it yet. If there's something that's not in the roadmap that you think should be, I'd suggest starting a thread on the play-framework-dev list to discuss.

Greg

--

You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/1dc0b9e8-f940-48b6-9331-ae5b932be487%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Slinn]

Greg,

Is there a tracking system for Play Framework 2/3 proposals where ideas
can be surfaced, discussed, rank-ordered and ultimately placed on a
timeline? A more transparent process would make a difference.

Thanks,

Mike

[Greg Methvin]

Github issues are appropriate for feature requests. We can discuss there and assign the issue to a release milestone (3.0.0, 2.6.0, 2.5.7, etc.). We don't have any other public tracker for new features. I'm open to ideas.

Greg

Mike

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2fdf1dd6-1b7e-d37e-002f-9f413f253fd2%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Slinn]

Yes, that approach works well for other projects, and it should work equally well for Play Framework.
I tweeted the milestone URL from @ScalaCourses so the world knows how to find it.

Many of the items on the roadmap Google Doc have not been captured as issues so they do not appear as milestone items. Once that is done the roadmap Google Doc would be redundant. To reduce confusion, the contents of that document should be replaced with a redirect to the GitHub milestone page, when ready.

Some sort of permanent link from this Google Group to the Play Framework milestone page on GitHub would be good to have.

Mike

[Greg Methvin]

Hi Mike,

Thanks. That's basically the plan. We're already linking to the pull requests but we should be creating and linking to the issues from the Google doc. The goal of the doc is more high-level general planning and the issues/PRs are for details.

Greg

--

You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/3f207bae-1a59-4edb-81af-b4dd83fadafc%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Slinn]

Sounds really good

Mike