Hacker News Reader

Comment by currywurst | Hacker News Reader

Have you tried Java EE 6 ? JAX-RS in particular is a splendidly designed api for RESTful services. And then you can make single page apps instead of JSF. This method is even going have ide support in Netbeans 7.3 with wizard-driven Backbone/Angular app generation.

View on HN

JAX-RS is really nice for building APIs and I actually prefer the way it works to Sinatra, especially if using it with Groovy.

But, this isn't Sinatra vs EE6, its Rails vs EE6, so its not a proper comparison.

To compare with Rails you've got to look at other parts of EE6: JSF + CDI + JPA, which is an awful mess. JSF by itself is enough to kill its usability for many modern applications, the amount of state JSF carries around is ridiculous.

The article said Java, not JEE. In Java land, the choice is much broader than JSF or JPA. The main problem that people bashing Java had was always that it offered too many choices. Ruby had Rails while Java had JSF, Struts, Struts 2, Tapestry, Wicket, Play. Rails had ActiveRecord, while Java had JDBC, Hibernate, MyBatis, OJB, EJB 1/2/3, JPA.

Ah, watch out for JSF, it's a dangerous place. JPA on the other hand is surprisingly good these days try Spring 3 Oliver Gierke has done good things.

JPA is fine, if and only if you've got a framework managing the entity manager lifecycle for you in a reasonable way.

In my opinion if I need an entire separate framework (or container) to manage it, I think its broken. I've switched to Ebean for Java ORM and am vastly happier now.

JPA also gets the award for the worst programmatic query building API I've ever seen. As a result it seems like the majority of people just use JPQL strings which is really annoying as its also SQL but not quite SQL.

The most painful component of Java EE development for me is definitely the JSF side of things. Without building anything substantial with JAX-RX I cant really comment. REST and a rich frontend, JS based would be my choice. The sad truth is that I live in a world where usable is beaten out by sellable.

Lots of real world apps don't compose nicely down to a bunch of REST bullshit.

Why not, specifically?

Complicated business logic, validation outside of a single object, workflows...

Can you be specific on how this is incompatible with RESTful bullshit?

Reply on news.ycombinator.com