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:

1. the amount of disk space we're talking about in either case is just tiny when measured in dollars, and
2. 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:

1. That was eight years ago! Is this really your best shot?
2. 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?
3. 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?
4. 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.

In case you missed it, Jay and Dan published an article about Ajax and JSF2 on DZone.

Since the release of Weld and Java EE 6, there's been a heap of activity in the Weld user forum, and especially a lot of questions about problems related to framework development. You can do some kinds of generic programming in CDI just using managed beans, producer methods and InjectionPoint. But if you want to get serious, you're eventually going to have to embrace the portable extension SPI. Here's a couple of examples of how people are using this SPI.

Steven Verborgh has written a nice tutorial showing how to implement a custom JSF view scope for CDI. Henri Chen has integrated the ZK framework with CDI (hopefully other web frameworks won't be far behind). Matt Corey has been experimenting with environment configuration via JNDI.

Meanwhile, I've been working on compiling user feedback into a list of enhancements to the SPI. We plan to roll the most important items into the first CDI maintenance release.

UPDATE: for completeness, I should also link Pete Royle's Quartz scheduling extension.

Andy Gibson has written a nice tutorial to help you get started with JSF 2 and CDI using Netbeans and Glassfish. It's great to see that both Netbeans and Intellij 9 already have excellent support for Java EE 6.

As I'm sure you've all seen, Java EE 6 has gone final. You can now download the Final Release of the Contexts and Dependency Injection, Bean Validation, Java Persistence API 2 and Java Servlet 3 specifications from jcp.org, and read the linked javadoc for the entire platform. It's also a good chance to check out the Java API for RESTful Web Services specification, which now includes CDI integration, if you havn't already.

Sun have also published a three-part overview of the new platform and the Java EE 6 tutorial and sample applications.

It's just fantastic to finally see the fruits of all that work :-)