So what's the best alternative for a Java shop?
I like JBoss Seam 2. It's worked out well for several sites.
Why I'm Moving Away from the Play Framework
51–60 of 88 posts
Re: Why I'm Moving Away from the Play Framework
#52cmiiw, but imho play is too similar with others web framework, like rails. i'd prefer scala community to push lift instead. lift has some great ideas, and has many things to improve.
>lift has some great ideas
Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks.
>i'd prefer scala community to push lift instead
The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
Re: Why I'm Moving Away from the Play Framework
#53cmiiw, but imho play is too similar with others web framework, like rails. i'd prefer scala community to push lift instead. lift has some great ideas, and has many things to improve.
>lift has some great ideas
Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks.
>i'd prefer scala community to push lift instead
The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
Re: Why I'm Moving Away from the Play Framework
#54Earlier quoted context omitted.
I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless…
Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.
Re: Why I'm Moving Away from the Play Framework
#55Play made it very very easy for me to target a jar from php. The php-java bridge at the time would start and stop the jvm with every request (I dont know how it stands up today). I did some research and was able to stand up a play server whose routes reflected classes/methods in the jar in about 20 mins. Are there other play-like frameworks for java?
Somebody mentioned Stripes in the blog comments, but it hasn't been update in a year:
http://www.stripesframework.org/
http://sourceforge.net/projects/stripes/
And by '...frameworks for java', do you mean Java specifically, or any JVM language. Several good options for the latter.
Re: Why I'm Moving Away from the Play Framework
#56I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes). I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts. Play is a very prescriptive framework but onl…
I've had to work with Play lately, and I find it quite delightful. It's butchering java as a language (or at least what's considered good practice), but since it works so well, you tend to overlook that.
I'm also a fan of maven. There's nothing better than checking out a huge project with a great deal of dependencies and just have it build perfectly with a couple of keystrokes.
Seems like the play developers (Guillaume et co) went for a clean break with legacy java though. And if you want that, you can't depend on maven.
Only had a cursory look at 2.0 so far, but moving further into Scala territory and adopting SBT seems like an interesting move to me. Play is becoming a great vehicle for Web developers who want to ease into a Scala future.
Re: Why I'm Moving Away from the Play Framework
#57Think I should mention this link https://github.com/playframework/Play20/wiki/Philosophy
Re: Why I'm Moving Away from the Play Framework
#58Nobody mentioned this link...
https://github.com/playframework/Play20/wiki/Philosophy
Re: Why I'm Moving Away from the Play Framework
#59Earlier quoted context omitted.
I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless…
Even without multithreading, mutating the value of a key (such that hashCode() changes) after putting it in the map entry won't return the same entry. This is a HashMap basic, not just something special jujitsu you need to learn with multithreading.
I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.
Re: Why I'm Moving Away from the Play Framework
#60I was surprised to see Typesafe throw its weight behind Play. While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me. Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it und…
> the compilation error reporting in particular
All too familiar if you use Eclipse :)