Java EE to the rescue again (RIP Spring – part 2)

Java EE has been a saviour on a number of occasions. Firstly, it saved Java from oblivion back when Sun thought Applets were the future of Java. It has also saved enterprises looking for a stack that doesn’t lock them in to a single vendor, single technology (looking at you MS).

So, as record numbers of developers and organisations are abandoning Java EE and Java in general, how can EE save the day again. The simple answer is simplicity. It sounds contradictory, that EE is the champion of simplicity but the evolution of Java EE has brought with it massive advances in reducing complexity.

What’s changed?

1. JPA – Hibernate led the charge into ORM and JPA cherry picked the best and now it is at version 2.1 there aren’t so many holes.

2. REST and JAX-RS – Restful is not a silver bullet, but sticking to the simplicity mantra, it is wonderful. Unlike almost all RPC protocols, it does the SIMPLE THINGS SIMPLY, but it still has the power and flexibility to deal with complexity. Implementing almost anything using SOAP, on the other hand is an arduous exercise, even if you just want to say, Hello World!

3. JAX-B – Like JPA, it has had it’s teething problems and suffers a little from poor implementations but now, maturity is on it’s side.

4. @Annotations – There are a few critics of annotations, however they tend to be academic. Separation of concerns, etc. Think of annotations as aspects but with explicit markers for the injection site. My pet hate is code being executed at runtime out of context from the actual source code. Annotations allow the runtime aspects without losing the source context.

Now, Java EE defines a bunch of specs. The relative success of a project based on EE is highly dependent on the implementations that you choose.

JPA Provider – Hibernate Vs EclipseLink:

Winner: EclipseLink
I have converted to eclipselink. There is 1 ‘feature’ of Hibernate that every developer has screamed at, at some point. LazyInitializationException! This is where you attempt to access a collection relationship from an entity after your session has closed. Not sure of the point of having ‘managed entities’ if you can’t pass them around. Basically, by the time the servlet filter gets around to serialising the entity to the client, the transaction is ended and the entity is no longer valid. There are many strategies to combat this, like OpenSessionInView, DTO, value objects, etc…. but every single one of these strategies adds significant amount of complexity….and for what? To ensure that the returning object is in the state you expected it to be when you first asked for it. So… if you ask for an object from the database, the JPA provider just grabs it’s key and a few fields. In the couple of milliseconds between then and when you start traversing the collections, someone else may have completed a transaction changing it. The serialised entity will reflect this change, not the state it was in when you asked for it (because your transaction ended). If this is non-negotiable, stick with hibernate. If you don’t mind if the provider just opens a new session and hands you the collection in whatever state it may be in and never ever have to deal with LazyInitializationExcection, EclipseLink is for you.

JAX-RS: Jersey + Moxy

There are alternative jax-rs implementations but I haven’t been driven away from Jersey. The JSON provider, on the other hand has been quite the source of frustration. There are a few choices, Jersey-JSON, jackson and EclipseLink Moxy. Jackson is far better than jersey but Moxy is a breath of fresh air. Moxy cuts out the middle man (XML) and serialises JAXB annotated classes directly and reliably to JSON.  is a native JAXB -> JSON provider. It is fast and simple and gives me predictable results. Jackson goes from JAXB -> XML -> JSON and sometimes serialises an array with 1 element as an object.

Glassfish vs JBOSS vs Tomcat

Finally, we need an application server and Glassfish is my choice. Again, it is simple yet powerful. Does the simple stuff simply and does not hold you back. As I am writing this the stable version 3.1.2.2, but 4.0 has just been released to support EE 7 and JPA 2.1. Nice! Glassfish 3.x + EclipseLink 2.4 has a rather inconvenient bug where ‘create-or-update-tables’ is not supported. Not really an issue in production, but a PITA during development. GF4 should also make these steps unnecessary.

 

Next instalment: 2013 WebApp blueprint

 

0 comments on “Java EE to the rescue again (RIP Spring – part 2)
1 Pings/Trackbacks for "Java EE to the rescue again (RIP Spring – part 2)"
  1. max says:

    .

    thanks for information.

Leave a Reply