Bruce Tate's Blog

JavaOne Archives

WHERE'S THE CHICKEN?

I love San Francisco. The cable cars, the wharf, the hills, the people. And oh, yes, the food. In truth, JavaOne has never been my favorite conference. I’m more of a chicken man than an elephant man, if you know what I mean. But you do have to love San Francisco and the food.

So I was looking for a restaurant with Michael Loukides (who edited my book but we’d never met personally), Dan Steinberg, Bert Bates and Kathy Sierra, some of the people in the publishing world that I respect the most. I was in heaven. In truth, we could have gone anywhere. Earlier in the week, a CEO who shall remain nameless called an Italian place Asian Fusion. And one night, I just went from party to party. But the different questions and different approaches to dinner time prompted this blog. So how would you expect different kinds of Java developer to approach dinner time?

Process

• The Rational Unified Process developers stand outside of the hotel and say “Who’s got a plan?” It’s a difficult problem, because they usually need a table for 50. We passed a few on Friday. I think they’re still outside the hotel, and they’d just decided on the top four places that can serve a table their size, but need to find transportation to San Jose. I'm sure that they'll settle on a good place, if they've got enough time.
• An agile programmer would ask “Which place is empty, so we can eat NOW?” They ask to see a menu. If they don’t like it, they just move on. They prefer local places that are a little less trendy for flavor and price.
• The extreme programmers just walk into the first place that they find. Some hesitate to eat with XP programmers, based on the unfounded fear that they will end up at some shady hot dog stand. They will only eat in pairs. And boy, do they eat fast.

Technology

• The trendy developer asks “Where are the people, so we can eat the best food?” In most cities, the trendy developer is looking for a service-oriented place with lighter fare, probably with chicken. Of course, in San Francisco for JavaOne, the trendy developers all wanted elephant. I mean, near the end of the week, you couldn’t find elephant anywhere within five hundred miles of San Francisco.
• .NET developers are fiercely loyal. Finding a restaurant’s easy. They always go to the same chain, but swear that the McFood’s just as good at their chain as it is anywhere else.
• BEA and SUN developers don’t really order. They just walk around reminiscing about the best meals they ever ate. Tonight, they’re having leftovers.
• IBM developers just call down to the lobby and say “Room service.” They’re usually very happy, but they’ve never had a meal outside of the hotel room. They can always find Elephant, even outside of San Francisco.
• Developers for the open source project that shall remain nameless go to the soup kitchen. They serve elephant for free there, but you have to let them lecture you while you eat. They swear that the company and the food are the best that you'd ever get anywhere. But if you complain to management, you may get yelled at, or even beaten.
• Developers for the Geronimo project go to a commune and start to cook. They’ll serve what they swear will be ambrosia that you can spread on your elephant or chicken, but they don’t have any food there yet.

Architecture

• The AspectJ people never eat. They carry around a direct drip of Glucose and Caffeine IV drip.
• The MDA people don’t say anything. They have been waiting to be fed since the mid 1980s.
• The SOA developer asks “So what does food really look like, anyway?”
• Lightweight container developers send folks from place to place. At each place, they say “Give me the best you’ve got.” Then, they settle down and eat in the park. Most people would never put those combinations together, but to them, it all tastes like chicken.

On a very slightly more serious note, I was wondering where to find the chicken at JavaOne. I mean, as I write this, the top 2 Java books on Amazon and book pool are Rod Johnson’s book called Expertone-on-one J2EE without EJB, and my book on the lightweight movement, Better, Faster, Lighter Java. (They go very well together, by the way. My book introduces principles that sell and support the movement to those unfamiliar with it, and Rod’s book talks about more practical concerns.) It’s amazing to me that the powers that be thought that a slightly improved programming model slapped on to the top of EJB was really all that we needed. I really don’t think they’re getting the message. That's OK. I already know where to find my chicken.

JDO: Let the games begin

From the very beginning, the JDO specification has been surrounded by controversy. You want drama? Consider the new startup specification against the establishment of relational database vendors and TopLink, the leading OR mapper. You want strangeness? Consider a specification for transparent persistence without any object relational mapping at all. You want a full-out bare-knuckled brawl? Consider the vocal conflicts between vendors like CocoBase and the JDO vendors; the facts and the fud surrounding byte code enhancement, and the pure transparent technologies of the lightweights against the cumbersome persistence of the establishment.

For all of the world, it looked like JDO was going to die a slow, lingering, silent death. EJB succeeded based on the sheer marketing muscle of IBM, BEA, Oracle, and to a lesser extent, Sun. Then, after a backlash against EJB, many returned to JDBC with POJO. TopLink stumbled and slipped, and it looked like persistence in general was going to take a back seat for a while.

But a funny thing happened on the way to the grave. Hibernate awakened the masses with an elegant, pragmatic implementation. And JDO began to show up again. Like the ragged peasant in Monty Python's Holy Grail, JDO just wouldn't hurry up and die; it wouldn't get on the cart (of dead plague victims). Little nimble vendors like SolarMetric effectively evolved JDO technologies, and brought it into the relational mainstream. JDO Genie built a simple and effective user interface.

So the expert group built a very strong 2.0 specification, patching the major holes in JDO. It's actually a model for how the JCP should work: they used practical, real-world experience to dramatically improve the previous version. And the intrigue started all over again. BEA, IBM and Oracle no-voted the JDO spec, and Borland abstained, but everyone else voted for it. EJB 3 announced that CMP as it existed was basically dead, and would be supported for backward compatibility. Instead, it would be replaced with a POJO persistence model. Gavin King, creator of Hibernate, joined the expert group, and it looked like EJB 3 would in fact be Hibernate. And some members of the expert group fed that false impression. The JDO community wailed. Surely, this time, they would have to get on the cart.

Then, many in the standards community got together and decided that it might be important to break persistence away from the EJB specification. As far as I know, the persistence specification is unsettled, and JDO has a tremendous opportunity to take advantage. They’ve put out an early specification. It’s been very well received. And here we are, at JavaOne. And the drama continues, but this time, within the JDO community.

First, Versant and Kodo announced that they were ending their co-marketing relationship. By itself, this would not make sense, because SolarMetric liked the increased visibility in this marketplace, and Versant liked having an increasing presence around relational databases. The move was quickly explained when Versant announced the acquisition of JDO Genie, a lesser implementation with inferior mapping capabilities, but still, a market player based on innovative user interfaces and ease of use. The message from Versant is clear. Relational databases have won. Nowhere in the JavaOne media guide could you even find the word object-oriented database in the Versant literature. They seem to be strongly targeting the relational community, and based on continually declining market for OODBMS, that’s a sound move.

For a return salvo, SolarMetric hired the independent giant, Robin Roos, effectively showing the rest of the persistence industry that SolarMetric planned to compete in Versant’s back yard. Finally, SolarMetric bolstered their application strategy by announcing a tighter integration with Spring. That effectively gives Kodo features like declarative transactions without having a full application server. So SolarMetric’s counter moves look to be aggressive.

So in the shadows of JavaOne, big things are happing all across the JDO landscape. It’s an important one to watch, because I believe that the Kodo product is the best high-end implementation of transparent persistence today. (I like Hibernate on the low end.) What happens next? Stay tuned.

This work is licensed under a Creative Commons License.