With the release of Java EE 6, I've seen a number of recurring, but rather curious, arguments against upgrading to the new platform. These are usually deployed by folks who are using a homegrown
stack consisting of a servlet engine like Tomcat or Jetty together with a number of open source frameworks like Hibernate and Spring.
Now, of course, I'm sure there are plenty of good reasons to choose a non-standard open source technology as an alternative to, or in addition to, a technology included in the EE platform. Happily, you're free to use whatever open source frameworks you like in EE 6 - indeed, Servlet 3 and CDI include a bunch of functionality to make integration of third-party frameworks as seamless as possible. So this doesn't amount to a reason to not use EE 6.
Rather, I've seen people saying the following:
Upgrading the EE application server is hard
This seems to be an organization-specific political problem, rather than an actual technical problem with the application servers themselves. Certainly, upgrading a server like GlassFish or JBoss is usually a pretty trivial task. (And upgrading third-party frameworks is certainly not always painless.) Apparently, some organizations have put in place extremely heavyweight processes surrounding server upgrades, without introducing similar processes for frameworks which run inside
the server, thus making it easier for the development team to deploy upgrades to third-party frameworks than to the application server itself.
Well, this sounds to me more like an argument for developing more responsive processes than an argument for abandoning Java EE. There are certainly risks associated with running your application on an old or obsolete server platform, and your processes shouldn't encourage that practice.
But from a practical perspective, almost everyone is going to want to upgrade to Servlet 3 in the near future. This means a server upgrade, whether you're using Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle or WebSphere. This is an excellent opportunity to simultaneously migrate to an EE 6 web profile. A golden opportunity, in fact.
EE application servers are bloated
The objection is that the EE server includes functionality that the team is not (currently) using. Well, then don't use it! Oh.
This argument usually devolves into a discussion of jar sizes, and a comparison of the disk space occupied by the servlet engine and third-party frameworks versus an EE application server deployment. Upfront, there's a couple of things wrong with this argument:
- the amount of disk space we're talking about in either case is just tiny when measured in dollars, and
- the size of the application war file is actually more important than the size of the server installation, and including more functionality in the server helps reduce the size of the war.
But by far the biggest reason to reject this argument is that the new Java EE 6 web profile is so obviously not bloated. When the first certified web profile servers make it into the market place, we'll have a new just right
sweet spot between too big
full EE application servers, and too small
servlet containers.
J2EE and EJB2 sucked!
The idea here is that we can take revenge on the people who gave us entity beans by refusing to use anything else that has gone through the JCP standardization process. Of course, this is a special form of revenge
which involves the user cutting off his own nose. Oh and:
- That was eight years ago! Is this really your best shot?
- Several great specifications have emerged from the JCP, some of which you almost certainly are using. No, the JCP has not had a 100% success rate - far from it - but then, who has?
- Most of the folks who worked on EE 6 hated EJB2 and J2EE just as much (or more) than you did. That's why they joined the JCP - to help fix the problems. For example, the, ahem, author of this blog post was the creator of Hibernate. Are you really trying to give him a lecture on the problems of EJB2?
- The folks who invented entity beans have probably all retired by now!
The truth is that the technologies in the Java EE 6 web profile range from very adequate
to cool as shit
. You're doing yourself and your employer no favors by not trying them out for yourself.
Application server portability is a myth!
Really? Then why do we see so many people porting applications between different application servers? Oh, I see, you mean 100% perfect world zero-changes-to-my-application platonic ideal portability. Well, OK, I understand that the nerd mindset has a weak spot for absolute truths and platonic ideas, but can we take a step back in this case, please?
In which scenario are you really better off, from a portability perspective:
- 99% of your code, and 85% of your external metadata is compatible between server platforms - and the remaining 1% and 15% can be ported reasonably easily
- 40% of your code and 80% of your external metadata is tied to a non-standard, single-vendor container architecture
When I make this point, it usually results in an immediate subject change from application server portability is a myth
to I don't care about container portability
. Well, OK, that's a value judgement that you're entitled to. But your subject-change concedes the point that application server portability is real. And it's useful to many organizations.
UPDATE: I'm still waiting to see a more substantive critique of EE 6 from advocates of alternative technologies. I consider the arguments mentioned above to be non-substantive, in the sense that they don't raise real, technical problems with the usability of the EE platform for application development. The quality of the latest round of specifications seems to have left the anti-EE camp (temporarily?) short on ammunition.
