Via TSS, I found this excellent post. Unfortunately, while I appreciate the sentiment (hell, I'm not so young and commitment-free no more), I'm simply not convinced that these things are actually myths. Sure, age discrimination sucks, I guess, and I'd like them to be myths, but is it really a myth that:

Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don’t have.

Or that:

Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones.

C'mon, let's give these young snippets their due! Lots of young guys really are smart, hard-working and enthusiastic. And their crazy ideas are much too often shot down by experienced, but clueless, people in more senior roles.

Sure, there's lots of reasons to want some more level-headed folks floating around the project somewhere, but you're going to have to do more than simply assert that these things are myths before I'm going to drop my (totally-based-on-personal-experience-so-take-it-with-a-grain-of-salt) belief that younger folks are, on average, more productive than older folks.

And now let me flip this around a bit: is the incredible salary discrimination (5x, or more) against younger developers really defensible?

Norman Richards has left Red Hat to work for a startup company. Thanks, Norman, for all your work on the Seam project over the last 4 years, and good luck with your new endeavor.

Norman leaves us with a funny blog post showing how many large companies scare away talented potential employees like Norman, one of the many things that makes it hard for large organizations to stay competitive and innovative.

The guys at Caucho have an interesting write up about their decision to aim for EE 6 Web Profile compliance. It's worth hearing their take on the new platform.

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.