Never used Jersey so cannot comment on ease of use at the code level. It may be similar, but it'll likely not have other nice features that Play has that sets it apart from other Java Frameworks.
I was comparing against any Java Framework that depends on J2EE and JSP though as that comes with an excessive amount of baggage that's really hard to get rid of totally (like excessive use of XML tooling/configuration). If one's reason for never touching Java on the web is because of the XML nightmare it generally brings, then Play is the framework one has been searching for. There's no use of XML anywhere that is required and templating/views are similar to what one would do in any scripting language since they're really Scala (Lift) templates and not kludgy JSP that reminds me of ColdFusion.
Also, being built on Scala shapes Play 2.0 in ways that other Java Frameworks are not by design, since Scala is generally against excessive verbosity and it's a Java habit that dies hard for some even when trying to avoid it.
I'll admit I'm biased against excessive XML tooling and configuration, since I come from a PHP & Python background in web development, but I dislike all that boilerplate. I realize it's sort of a common part of almost everything Java, but it's also why I stay away from Java on the web as much as possible.
Edit: Jersey does make use of JSP[1] (Java Server Pages). Some may not find that to be bad thing if they're used to it from prior experience, but I would avoid it personally. If coming from a dynamic programming background on the web (Node.js, PHP, Python, Ruby, etc), JSP is not a fun time.
Jersey is really easy to use as strictly a REST backend. I fully grant that Java is, in general, more verbose than Scala. Just curious if you were comparing this based solely on past experiences. (That is, when making a "service" with Jersey, there is surprisingly little boilerplate. There is the verbosity of Java, but pretty much none of the other.)
And, really, it mainly depends on how you want to structure your application. At face value, an angularjs/whatever frontend that calls to whatever REST implementation you can bring to works quite well.
Regarding JSP, yeah, planning on avoiding that as much as possible, though, for a quick "put a dummy string into a page," I can't say it is that terrible. (I fully grant that is a very slippery slope.
I was comparing against any Java Framework that depends on J2EE and JSP though as that comes with an excessive amount of baggage that's really hard to get rid of totally (like excessive use of XML tooling/configuration). If one's reason for never touching Java on the web is because of the XML nightmare it generally brings, then Play is the framework one has been searching for. There's no use of XML anywhere that is required and templating/views are similar to what one would do in any scripting language since they're really Scala (Lift) templates and not kludgy JSP that reminds me of ColdFusion.
Also, being built on Scala shapes Play 2.0 in ways that other Java Frameworks are not by design, since Scala is generally against excessive verbosity and it's a Java habit that dies hard for some even when trying to avoid it.
I'll admit I'm biased against excessive XML tooling and configuration, since I come from a PHP & Python background in web development, but I dislike all that boilerplate. I realize it's sort of a common part of almost everything Java, but it's also why I stay away from Java on the web as much as possible.
Edit: Jersey does make use of JSP[1] (Java Server Pages). Some may not find that to be bad thing if they're used to it from prior experience, but I would avoid it personally. If coming from a dynamic programming background on the web (Node.js, PHP, Python, Ruby, etc), JSP is not a fun time.
[1] https://github.com/jersey/jersey/tree/2.3/examples/bookstore...