Building REST services with JAX-RS is truly pretty smooth and quick (I've been using Jersey not Wink though).
One thing I don't ever recommend is using JPA based libraries (Hibernate, EclipseLink, whatever). Run screaming away from that spec as fast as you possibly can. There are much better options for ORMs in Java that don't have the session management headache and endless string of gotchas that is JPA. Ebean is my current favorite.
As for the "framework", I haven't really found the need for one. Jersey/Jackson + Jetty + Ebean gets you 90% of the way there, just fill in whatever you want for logging and other minor support items. If you want something more pre-packaged with some of the service start/stop boilerplate built in there is dropwizard (https://github.com/codahale/dropwizard).
Nice. +1 for avoiding JPA. I hadn't heard of Ebean, I'll look in to that. Shameless plug, but Joist is my take on a "post-Hibernate" back-to-the-basics ORM:
Wise comment about JPA, it's full of gotchas and just when you need something fancy that you think will justify all the troubles of setting it up, you find that is impossible either because of a bug in your provider or because the spec just didn't cover that case.
On the rest side the real beauty of it over SOAP is that you don't really need a framework, I use Spring MVC but I set it up to the barebones because much of it is not needed.
I don't hate ORMs, but I hate when they are too intrusive. What I like about Ebean is that it was designed to only handle the simple stuff "ORMish" and provide a very smooth and easy breakdown to raw SQL so you get the best of both worlds. I also love "autotune", it tracks your call stack for queries and after it has enough statistics it'll start only fetching the fields that you actually ended up using. So if you have an object with 25 fields and one page A you only use 5 of them, it'll only fetch those 5, but since its based on a the call stack and not hardwired into the model, it can can track that you used 5 different fields on page B and optimize that query too.
I didn't quite understand it. From your example, it looks like ORM layer knows about 'pages', which are in views. Isn't it against clean separation of concerns?
It doesn't know about pages, it knows about the stack trace that resulted in a query being generated, e.g. it know that a specific method in the ProductController called a specific method in the ProductService, etc, leading to a query being generated.
It also know which fields of the object it returned were accessed prior to going out of scope and more importantly, which fields were never accessed. With those two bits of information gathered over many calls it can figure which fields are actually worth fetching from the database and which should be left off and fetched lazily in the odd case that they are needed.
JPA does have some gotchas and the learning curve is a little bit steep (not too steep, but just a wee bit).
You do need to know how JPA works internally a little bit (e.g.: EntityManager actually cache your objects unless you tell it specifically to "flush").
1) CriteriaBuilder API is the worst API I've ever seen. I've never seen an API that turns a simple task into more lines of code than this monstrosity. I can't imagine many people use this thing, instead they use JPQL losing type safety in the process.
2) JPQL is still wildly verbose and very difficult to intertwine with native SQL. As an example try to generate something like "SELECT * FROM `order` o ORDER BY RAND() LIMIT 5". That little call to RAND() makes generating this from JPA a huge pain.
3) Manual session life cycle management is terrible. It shouldn't be needed. This leads to all sorts of terrible hacks to get around it, ConversationScopes(CDI in general), opening transactions in the JSF RENDER_RESPONSE phase just so lazy loading works, etc, etc. Having used JavaEE stuff for awhile now I'm convinced a large portion of the cruft exists to support this model of session management. All the additional scopes and requisite CDI support seem to have all been created as workaround to just deal with session lifecycle.
>CriteriaBuilder API is the worst API I've ever seen.
It's not great, but it's type safe. Having said that, I do C# so I just use Linq but before Linq I was using CriteriaBuilder. It wasn't so bad because I was only using it in specific repository objects, not all over the code.
Thanks a lot for the pointers. I have been looking for a good java framework to learn. I will be more than happy to settle with this 90% you quoted. They look simple enough to understand in a couple of days without wrestling with tons of XML config files.
If you're looking to write a backend service using Java, I would take a serious look at dropwizard http://dropwizard.codahale.com/
The get started page is not that long, and you should be able to kill it in a few hours. At the minimum you get http requests routed to methods and restful json parsed for you automatically. If you want, you can add optional configuration, metrics, healthcheck, logging, db access, views etc.
I should add that my "90% of the way there" gets you a service that easily speaks JSON via REST calls. Its all you need if your frontend is backbone based or its just a service getting called by another layer. If you need to actually render web pages in response you'll need something for views/templating, freemarker is a reasonable option and JSF isn't terrible if you avoid half of it (looking at you ViewScoped). But, honestly, I would do the page rendering elsewhere, I don't think there is a good Java answer for this, maybe the Play Framework, haven't used it much yet.
In my case the Java backend exposes RESTful models via JSON which are consumed by a rails app using Her[0] a great gem that is what ActiveResource should have been. It wires up to Jersey quite easily.
You don't need JSON configuration even if it was existing.
You can use annotation based configuration (meaning Java classes with annotations like @Configuration, @EnableWebMvc etc..) for > 90% of the configuration cases:
I prefer plain files instead of annotations. Just wish the non-readability of XML would go away with less bloated format (which other frameworks did with JSON).
I mix them usually. Layer-oriented stuff like @Transactional and @RequestMapping incl. Path/HTTP Method etc. in the code, central declaration stuff like e.g. Marshallers, HandlerAdapters, global ExceptionHandlers in XML...
Usually reserved for legacy databases with lots of custom queries and jdbc code, mybatis (previously ibatis) is a pretty flexible solution. Hooks into Spring pretty well too.
Besides the frontend code being much simpler (Javascript can do a lot of fancy stuff when it receives nicely structured data instead of dumb HTML) another huge benefit was enabling other people with different language backgrounds (Perl in my case) to perform their QA on the resulting API instead of manually clicking through the app (or writing quickly dying Selenium tests due to page modifications).
In the meantime even the customer does use the API for integration purposes using curl :)
One thing I don't ever recommend is using JPA based libraries (Hibernate, EclipseLink, whatever). Run screaming away from that spec as fast as you possibly can. There are much better options for ORMs in Java that don't have the session management headache and endless string of gotchas that is JPA. Ebean is my current favorite.
As for the "framework", I haven't really found the need for one. Jersey/Jackson + Jetty + Ebean gets you 90% of the way there, just fill in whatever you want for logging and other minor support items. If you want something more pre-packaged with some of the service start/stop boilerplate built in there is dropwizard (https://github.com/codahale/dropwizard).