A Kinder Gentler Java

I just got back from JavaOne.

This year's major trend seems to be a movement toward simplicity.

The years 1999 through 2003 were all about making Java powerful and scalable. But that also made Java somewhat complex and unwieldy. And now Java needs to be made simple without losing that power and scalability. That is exactly what is well underway.

Some of the buzz-phrases I heard in many sessions at JavaOne are "Inversion of Control (IoC)", "Dependency Injection", "Annotations", and "POJO-based solutions".

What these all mean is that more of the responsibility for the configuration and management of Java Resources is being given to the Java Framework, so that coders have much less to worry about. In fact, Java coders will have so little overhead to deal with, that their enterprise-grade solutions can be implemented using just POJOs (Plain Old Java Objects), and not something fancy like true Enterprise Java Beans.

The Open Source community has been leading the way in this movement, with frameworks like "Spring" that provide a lightweight alternative to EJBs, and "Hibernate" which provides a lightweight alternative to Entity Beans, and Spring-MVC which is a lightweight alternative to Struts.

And the official Java Standards Community (Sun, IBM, Oracle, etc.) has noted the benefits of these trends, and they seem to be implementing their own "Best of Breed" solutions into the new Java Standards. For example, Sun gathered experts from the Hibernate, Toplink and Spring projects to help them develop the new EJB 3.0 Entity Bean spec. The next version of the EJB spec will be considerably more lightweight and require little or no configuration by the developer.

I was impressed by the sense of community and cooperation that existed among all these technology groups. Because in the real-world, many of these technologies will compete head-to-head, or at the very least step on each other's toes where they do overlap.

But that's the great thing about Open Source: People are not as motivated by money and market share. They are more motivated by having a free exchange of ideas and options, and helping the Java Community as a whole.

The downside is that I felt like I came away from this conference with a wide variety of choices and no clear "best" path for any given situation. And since everything is in flux, the best choice today might not be the best choice for a year from now. In one session, I was given 10 great reasons to use Spring, and then in the very next session I learned how the new EJB spec will effectively erase or replace 5 of those reasons. So...do I use Spring today for the immediate value-add that it provides, or do I wait to implement more standards-based solutions later? Maybe I just use a little bit of Spring here and there, so long as I don't depend on it. And Spring seems to be very good at letting you use as much or as little if it as you want.

All of the presenters were quick to point out that all these technologies can co-exist. I could use Struts and JSF and Tapestry all on the same project. But that itself is a form of unwieldy complexity, and that is what we are supposed to avoid, right?

The Java philosophy seems to be one of "Let a thousand flowers bloom". And that is in stark contrast to "One Microsoft Way". I think I prefer the Java way, but I do fear being caught in the lurch if I pick the wrong flower.

Topics that are definitely on my radar for research in the immediate future:

1. Generics - Type-safe collections and static type-safety constraints in Java. And it's about time! And it's part of the Java 1.5 standard. Gotta use them where appropriate.

2. Spring - I've been aware that Spring was gaining market share for over a year now, but I didn't think it had reached critical mass yet. I came away from JavaOne with the definite impression that it's ready to be used; mostly because Spring is so unobtrusive that there is very little cost or commitment in implementing it.

3. AJAX - I'd like to thank Kendric Beachey for coining the phrase "Kluge Cage". Because that's what AJAX is (in my opinion). JavaScript is a horrible language, and it doesn't even work the same way across all browsers. But AJAX is a framework written in JavaScript that wraps a clean interface around what would otherwise be a MESS of JavaScript required to perform rich client interaction on the browser. And even if the insides of AJAX are made of gloop, the "Kluge Cage" holds it well, and power it brings to a browser cannot be ignored. It's everything that Flash and Java Applets have tried to be, but implemented in a way that is natively supported in all browsers. (Unless some user disables JavaScript). Plus, there are already component libraries released that will allow you to integrate AJAX with JSF.

4. EJB 3.0 - I was blown away by what Sun plans for EJB 3.0. No Home Interfaces, no JNDI, no deployment descriptor, use of annotations, dependency injection, and lots of defaulting behavior. More powerful that previous EJB specs, and yet much simpler to use, and still backwards compatible with EJB 2.1. Wow. EJB's might finally be ready for general use!

5. Apache MyFaces - This is the Apache implementation of the JSF standard. Apache usually makes good stuff that goes above and beyond the Reference Implementation. I need to research what they have here.

6. JSF native support for Portlets - A portlet is one of those technologies that seems really cool and useful...if you can just find the right time and place to implement it. But time and place are always in motion, so I need to get up to speed on the Sun Portlet spec early so that I will be ready for it. But one thing I learned is that JSF is definitely the best framework to be using if you want to Portlet-enable your applications.

7. SOA - Service Oriented Architectures - Not quite ready for prime-time, but definitely a topic to watch. SOA is still in the "buzz-word" phase. SOA can be done with existing technologies (WebServices, EJB's, XML, etc), but it isn't as easy as it needs to be. At the moment there are lots of 3rd part vendor tools that are promising to make SOA easier, each in a slightly proprietary way.