A Sleepy JavaOne

By Allen Holub

June 15, 2006 —

As I write this column, JavaOne is just winding down. This year’s conference was one of the biggest ever, but interestingly, the least energetic of them. There was just nothing new to engender the sort of buzz that I’ve seen at some prior conferences.

Part of the problem is that the hot topic of the minute is AJAX, and the server side of an AJAX transaction is old-hat Java stuff: servlets and the like. A lot of the sessions were devoted to the client side, but the client side in AJAX is entirely JavaScript, not Java.

The one truly interesting AJAX-development development was Google’s new GWT package (Google Web Toolkit, at code.google.com/webtoolkit), which lets you develop the browser-hosted client side entirely in Java. GWT includes a widget library that you program in Java, and a compiler that translates that Java to JavaScript for deployment on your Web page. It’s a way to do AJAX without having to write any JavaScript at all.

In spite of the claims I was hearing to the contrary from the JavaScript aficionados, I think that JavaScript is a miserable, inherently buggy language. Since GWT lets you continue a true object-oriented paradigm onto the client-side code, it actually makes AJAX viable, something that I’ve been dubious about up to this point.

There were a few language/API-related changes of interest.

First of all, there’s absolutely no excuse for not using Java 5 if you aren’t already. Java 5 is just plain better than all previous versions.

Java 5 incorporates language features that make your code better (more reliable, with less syntactic clutter); it is supported by every major platform and vendor; and unlike any prior Java version, Java 5 has measured five-nines reliability. Most important, all of the significantly cool things that were demonstrated at JavaOne require language features that are unavailable to you in prior Java versions (primarily annotations). Upgrading your system to Java 5 should be a major priority.

Those “significantly cool” things fall mainly into the J2EE (now called Java EE) department. The EBJ 3.0 “Simplified API” and the new Persistence system are big news.

On the EJB front, pretty much all of the error-prone infrastructure is gone. For example, you can make a stateless session bean by declaring a normal Java class (a POJO, if you will) with the annotation @stateless. That’s it. No Home interfaces, no getter/setter functions, no deployment descriptors, no complexity.

There’s still a complex, impossible-to-use, 850-page EJB specification, but the Simplified API, which sits on top of this abomination, is vastly better. More to the point, the Simplified API isolates you from the horror that lies beneath it. It’s what EJB should have been to begin with.

Of course, the new Simplified APIs are like a nice suit on a putrefied corpse. Fortunately, there’s nothing at all stopping you from replacing the corpse with something a bit less smelly. That is, you can do a clean-slate implementation of the new APIs with literally none of the old EJB stuff under it, and at least some of the EJB vendors are moving in that direction, at least as an option. Clean-slate implementations will not be at all compatible with existing EJB code, but they will be faster, more reliable and a lot smaller.

If you’re doing any EJB programming, I’d advise you to use the new APIs for all of your new work, and gradually refactor your existing code to eliminate all mention of the old APIs.

The new Persistence APIs flush out the system. Entity beans are now gone. Instead, you have JDO/Hibernate-style persistent objects. As with the EJB APIs, everything can be done with a few simple annotations (@onetomany, @manytomany and so forth). No more complicated XML configuration files!

On the O/R-mapping front, you can accept the compiler’s notion of what the SQL can look like, you can use an annotation to specify the SQL as part of the Java class definition, or you can specify the SQL in a relatively simple XML file. The JDO query language has also been improved considerably, now supporting such things as inner and outer joins and nested queries.

All of the above are implemented in Sun’s Glassfish app server, available from https://glassfish.dev.java.net/public/users.html.

These changes are welcome and long overdue. Now we can move forward with a set of simple APIs that will make hard tasks easy to do.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/29376

From JavaOne to JavaOne-Half The most interesting thing about this year's JavaOne was that it wasn't-interesting, that is. Over the years, the conference has...

Microsoft drops in on JavaOne Acknowledging the interoperability between Java and .NET, Microsoft signaled that the war between it and Sun is now over.

JavaOne was not just Sun's show While Sun was the major player at the JavaOne convention, a host of third-party companies also made their voices heard and showed off what they have to offer.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST