I view that as a good thing, as cool concepts like Iteratees have been inspired by functional programming and Scala. There aren't many frameworks out there that make it easy to develop traditional websites and web services and do comet/websockets with ease. There aren't many reactive frameworks out there, period.
I also hated Play 1.x because it relied on its own half-baked build system, making it hard to import Maven modules and because the templates were written in Groovy, which for me was a big turn-off, because I like the JVM for its potential for performance and using such a slow dynamic language for its templating was a big no-no (Groovy may have gotten better in the meantime, I don't really know). It also relied on many runtime hacks and bytecode generation, things that have been moved at compile time in Play2 with the help of its SBT integration.
There's many things to like about its preference for the Scala way of doing things. Don't let that stand in the way, as otherwise it's a nice framework.
> Groovy may have gotten better in the meantime, I don't really know
Last year Groovy 2 was released which provides a @CompileStatic annotation which directs the compiler to statically compile the tagged code which runs faster. Not many people seem to be using it though, e.g. Grails and Gradle only use dynamically compiled Groovy code (afaik). And it's still quite buggy, e.g. just yesterday this serious bug was reported: http://groovy.329449.n5.nabble.com/BUG-in-CompileStatic-mode...
You mean they have added @Annotations to XML file editing. Many frameworks still require you to edit XML files too in some places (Maven/Ant/Tomcat config etc.).
In the application code, you can use either annotations or XML, or both, it's up to the developer.
And regarding editing XML in some other required places - you can use Gradle instead of Maven or Ant (thus no XML files). But that's not the point, to get rid of all XML on your server. The point is that in the application code you are not obliged to use XML.
If you are doing much beyond simple bean injection - Camel, Quartz, OSGi, etc. - then you will be up to your armpits in XML. But it's not so bad, if you prefer configuration to convention.
And don't forget Spring MVC, my favorite choice. Since Spring 3 it supports complete annotation based configuration. And it's completely configurable to leave you choose whichever templating solution (e.g. Thymeleaf)
I have found RESTEasy (and likely any JAX-RS implementation) to be very nice for creating simple services. With various annotations and static typing to automatically convert various parameters into function arguments, it's easier than Sinatra on Ruby. (Of course, there's a bit of config overhead to hook it into a web.xml, but it's not terrible)
I've heard great things about Play. When I had to choose a Java framework about 2 years ago, I chose Stripes, and I've been very happy with it. But I notice that it doesn't even get mentioned in discussions like this one. Wonder why that is.
One of the biggest (maybe the biggest?) contributions to language and framework adoption is marketing in the form of blog posts, training sessions and quality tutorials. This is why RoR is so popular even when it isn't all that great (there are many technically superior alternatives across many languages) - it has amazingly good marketing for a framework.
So to answers your question: you don't hear about Stripes because Stripes is bad at marketing. Just look at their website - it looks like its from the 90s. A small bit of CSS work is probably the best thing Stripes could do to increase user base.
I dabbled in Stripes a while back(moved job, now on Spring3), and I liked it as well. Lightweight and easy to use but lacked decent support and user traction. No reason it's not used more, and I don't know why either.
The big exception is Play! Framework but that seems to have mainly shifted over to the Scala side of things.