Hey Hugo,

I've somehow become a bit of a devil's advocate for Java lately. Thanks for pinging me - happy to offer a few thoughts.

I've not actually tried using Jersey/JAX, but it looks like a very clean setup for quickly writing low-latency JSON APIs. I'm impressed by the Getting Started example (here: https://jersey.dev.java.net/use/getting-started.html) and find the use of decorators to specify path, methods, and content types creative.

As for the rest, keep in mind that you don't have to use anything that you don't want to. I've done a fair amount of Java development and never actually used Hibernate, Maven, or JBoss. For the most part, the complexity that these tools can introduce, while great for many projects, kind of scares the crap out of me. Like you, I'd always go for the simplest workable solution available.

Jetty is a very nice, simple alternative to Tomcat/JBoss, though I find Tomcat to be rather nice myself. One thing I've come to love about Java deployment is that you're literally deploying just one file (a .jar or .war) rather than hundreds.

If you're looking for a nice, clean ORM, check out ActiveObjects by @djspiewak. Its design is based on the active record pattern, and it's very easy to get up and running with about any database as a backend. I used this on a large project ending a few months ago and had a great experience with it. Daniel's also available via Twitter and IRC and tends to be happy to offer an answer to a quick, informed question. Here's the post he introduced it with (http://www.codecommit.com/blog/java/an-easier-java-orm), and here's the project page. (https://activeobjects.dev.java.net/). I'd also strongly recommend checking out these docs he put together: https://activeobjects.dev.java.net/ActiveObjects.pdf

I really love the "static files + AJAX" approach that you've suggested (it's actually the same one mentioned in the project I referred to above). If you were to build something with Jersey and ActiveObjects, perhaps with a small caching layer in between (either an in-app cache if you'll only have one app server, or memcached), you will have produced a screaming API for your application.

The Play framework (mentioned below) is also very good, and has emerging support for Scala, which I and many others find to be much cleaner and more expressive than the equivalent Java. If you're feeling adventurous, I whipped together a quick little framework for building zippy JSON APIs and simple frontends via a lightweight wrapper around the servlet API. It's called Miso. Here's the info on that (and do ping me if you feel like playing with this - I may have a more recent version): [http://blog.paradoxica.net/post/401365886/hello-miso]. See here for docs, and especially page 6, which shows what a sample controller / API endpoint looks like: http://u.phoreo.com/gx.pdf

Of course, this also depends on whether you actually need that, and how much experience (or desire to learn) you have. If you're comfortable with Python, something like Flask or Piston might be more appropriate. At the same time, I would suggest that those who say that '"x language" or "y framework" makes developers infinitely more productive' aren't offering terribly productive advice, as I find myself about equally productive in Java, Scala, Python, and Ruby, and often opt for Scala or Java unless I'm hammering out something quick and imprecise. That is to say, it's definitely a matter of preference. So, choose what you think will make you most productive, or, choose to learn something new which might be a bit difficult at first, but will also teach you a lot about statically-typed languages and could potentially meet the needs of your application with far fewer resources and lower latency on the server-side for years to come.

Regardless of which path you choose, feel free to hit me up with any questions along the way.