Believe it or not. From time to time I get the chance to make a proposal for a technology stack to use. And it happened recently, that I did this. And after following my post about choosing the
right Java EE version I dediced to make a proposel for using Java EE 6 with GlassFish 3.0.1. And this proposal finally raised my awareness about possible risks, people could remark being confronted with such a decision. Here is how you could address them. And please note, that this is only one possible way that is drawn with a strong technology background skipping all the "maybes" and "technical details". If you have to argue for it, it's most likely, that you will see business decisions driving this more often.
Nothing changed (basicaly)
If you look at Java EE 6 from a technology point of view, you have a couple of single specifications contained in an umbrella. We are talking about roughly 35 technologies. Let's split them apart to see, what's important. Compared to the plain numbers, the heart of Java EE 6 is still Java EE 5. 52% of the specifications did not even get an update. They simply stay unchanged. We have 23% regular updates, 14% major updates (reworks) and only 11% of the stack is completely new. So nobody has to fear, that already taken investments in Java EE 5 skills or infrastructure will be wasted. It's more like a concrete evolution of what we have with Java EE 6. If you stay at 5 these days, you'll be betting on 4-year old technology and increasing your
Technical Debt.
Advantages and opportunities of the new ones
Let's look at how the 11% new stuff could influence our development and which opportunities are in there. First two are Contexts and Dependency Injection (JSR 299) und DI for Java (JSR 330). Both promise to make mature dependency injection capabilities know from frameworks like Spring and Guice available within the industry standard.
Next in line is the new Bean Validation (JSR 303) framework. It's presence allows for standardized and annotation based validation within your applications. And finally there are the RESTful Web Services (JSR 311). They allow a lightweight approach to connecting clients and servers. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it.
Significantly less workarounds and overhead
As one primary goals of Java EE 6 was to optimize the webstack and because of this it is primarily JSF 2.0 (JSR 314) which holds the biggest opportunities. Beside the fact, that you now can use facelets without having to deal with it as a library, you have many other advantages available. Think about scopes, resource handling, system events and native AJAX integration, to name but a few. All this is directly followed by Java Persistence 2.0 (JSR 317). It's the first usable JPA standard out there. You no longer have to use other persistence frameworks to get a working application. Sticking to the standard is now possible without workarounds or additional effort. The topping are the Enterprise Java Beans 3.1 (JSR 318). Forget about ejb.jar files and containers. Deploy everything in a single war. Use the new no interface beans, the singleton support and benefit from the new annotation driven timerbeans. To make it short. The reworked specifications consequently addresses issues from the field. Compared to Java EE 5 you now have significantly less workarounds and overhead in terms of third party libraries to handle.
How to manage the new kids
But there is still the risk, that the new kids on the block will fail and the concepts are not usable in a productive environment. How to address this? The first step is to have it on the list somewhere. Don't tell anybody, you are going to base everything exclusively on them. For a real life project it's best to find a strategy for staggered and suitable use of the new features. In fact, you could think about the right time to introduce the new features. Having a mature Java EE 5 stack at hand it's probably best to start with whatever you have. Straight away and think about the need to introduce any of the new specifications following these simple rules: 1) One at a time. 2) And always have a fall back strategy. The little graphic shows a possible scenario for this. Start with what you know best and introduce what you could handle. JSF 2.0 is a good starting point in general.
GlassFish is dead!
If you are done with discussing Java EE 6 and its advantages in general, you have the next point to talk about. The application server to use. To make it short: You only have exactly one choice at the moment. And this is something that could scare people to death. Be careful talking about it. But it's true, so you have to commit this somewhere during the discussion. The worst argument I heard lately was that someone read, that "GlassFish is dead". Wow. Awesome. Thanks manager magazines around the world. If this is not the message, you are willing to spread: This is how it arrives at your readers. Even if Oracle has it's own way of driving Java and even if they are not Sun and even if there are many things happening in the community at the moment. GlassFish is anything but dead! It's freaking alive and rocking. 24 million downloads since 2005. The reference implementation for both Java EE 5 (JSR 244) and Java EE 6 (JSR 316). The choice for many big accounts like
Peugeot,
Verizon,
Xerox,
Telefonica,
T-Mobile and many others.
And it's there since 11/2008. A stable version is available since 12/10/2009. So it's happy first birthday for Java EE 6 and GlassFish 3 today. But to be honest, the first tests started two years ago. And if you look at the release plan on the right you can see, that the commercial 3.0.1p1 fixed additional 7 bugs compared with the 3.0.1 released 6/18/10. That's a sign, isn't it? A good one!
Why everything has to be this hard
I know. The honest way would be to simply share the personal excitement: "Java EE 6 with GlassFish 3 is freaking hot and we need all those fancy new specifications.". But the truth is, that your daily jobs are there because of people asking you questions about risks and taking them into account. And there are still some scenarios, where I honestly don't want to use Java EE 6. But it's also true, that beside all political considerations there is nothing to worry about using it. If you are not working for one of those customers or shops requiring you to use blue or other colored commercial application servers, you are free to give it a shot. And it is worth it. Beside the technical advances
it will save you real money.
I've worked with Glassfish 3.x and Java EE 6 for most of this year, and now I'm on a Spring project, which compared to the leanness of Java EE 6 feels like a regression into the interface-and-XML-laden days of J2EE 1.4.
ReplyDeleteSo from the feature and developer productivity perspective, there is absolutely nothing to be afraid of in Java EE 6.
On the other hand, I've had a hard time with numerous bugs in the JPA 2.0 and CDI areas - with the 3.1 release announced for Jan. 2011, Glassfish will hopefully reach production quality, but it's not there yet.
So I totally agree to your advice to upgrade only one technology at a time.
There's mainly one thing I'm afraid of, and that's marketing and politics. A year ago, with the Java EE 6 and Glassfish v3, Sun and many independent consultants and bloggers would lead us into believing that this was most exciting platform ever and ready for production.
In reality, the quality was beta, at best.
Another problem is the lack of C in the JCP. Take JPA 2.0 as an example - there are three providers (Eclipselink, Hibernate, OpenJPA) certified to be JPA 2.0 compliant by the closed-source TCK.
Now given the number of specification violations I've encountered most notably in Hibernate, I'm really worried about the quality of the TCK and, by extension, about the whole issue of "Java EE compliance".
Java EE could gain a lot of credibility and quality by moving to a true community process. Open-sourcing all TCKs would be a first step in that direction.