Gavin King leads the Ceylon project at Red Hat. Gavin is the creator of Hibernate, a popular object/relational persistence solution for Java, and the Seam Framework, an application framework for enterprise Java. He's contributed to the Java Community Process as JBoss and then Red Hat representative for the EJB and JPA specifications and as lead of the CDI specification.
Gavin now works full time on Ceylon, polishing the language specification, developing the compiler frontend, and thinking about the SDK and future of the platform. He's still a fan of Java, and of other languages, especially Smalltalk, Python, and ML.
You can follow him on G+.
A few folks have been asking what the hell's happened to me, and I realized that I have not posted anything here for like 6 months. Well, the truth is, apart from recently becoming a father, I've been quite busy with a really exciting new project. And yeah, my head is full of a hundred interesting things I could blog about, but, unfortunately, the new project is super-duper secret for now, so I'll have to keep a lid on it until we're ready for an alpha release (perhaps another 6 months from now).
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.
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.
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?
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:
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.
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.
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.
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.
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.