Bruce Tate's Blog

J2EE Archives

Why the JCP will do the right thing by JDO 2.0

"Bring out your dead!"

Early this year, the JDO 2 expert group submitted the JDO 2.0 draft to the JCP Executive Committee, and requested permission to deliver a reference implementation. This is the standard process defined by the Java Community Process. In a startling reversal, the JCP executive committee did not accept the public draft.

"Bring out your dead!"

On the surface, to many on the committee, that may have seemed like a good idea at the time. The overwhelming sentiment of the executive committee was that Java needed only one common persistence specification, and the new persistence specification defined by the EJB expert group (for JSR 220) should fill that role. After all, how many ways of doing object relational mapping do we really need? And hasn’t JDO been all but dead, anyway? You can almost hear the Monte Python voices in your head, with the JCP expert group driving a cart full of carcasses, yelling "Bring out your dead." And on that cart, you can plainly see the festering bloated carcass of the elephant …

"I’m not dead yet."

Only, the whiny, little voice of JDO wouldn’t go away. Just as she’s being loaded onto the cart with the other Black Bloat victims, she shouts “I’m not dead.” In truth, hundreds of JDO customers are probably calling Sun as we speak. The reality is that if you couldn’t make entity beans work, and you wanted to do ORM with a standard API, then you were writing JDO. She just won’t shut up:"I feel happy!" But shouldn’t those JDO-zealots just die in peace, and let the executive committee lob just one more body onto the cart? I mean, what could it hurt?

"I’m feeling better."

Well, that depends on your perspective. Think of the customers who actually like JDO. Certain implementations do things that other frameworks just can’t. Solar Metric’s Kodo is much easier to manage than any of the EJB alternatives, or Hibernate, for that matter. You’ve got GUI tools that will monitor the execution, and help you tailor your caching strategy, or manage your eager/lazy scenarios. Versant’s JDO has an excellent user interface, making visual mappings much easier to create. So let’s assume that you’ve got a good reason to use JDO. You trusted the JCP when they accepted the first JDO standard. You may have turned your back on some proprietary solutions to pick a safer standard.

"Well, can you hang around a couple of minutes? She won't be long."

Now, just assume that the JCP votes down JDO 2. What do you do? Your situation has suddenly become much riskier. If you’re a JDO vendor, the rug has been neatly pulled right out from under you, partially by your competition. If you’re a customer, your vendors have been damaged, and you either lose maintenance and progress, or you must adopt a proprietary framework. If you’re the decision maker who chose JDO, you’ve lost credibility.

And what’s the alternative? It turns out that the EJB 3 expert group is supporting EJB 2 style persistence in name only. That one is a dead API. And right now, there is no credible standardized alternative! You’re really looking at late 2006 before you see any EJB 3 implementations in sufficient numbers. So you can go with a proprietary solution, a dead API, or you can bet on the JCP executive committee to actually adopt the combined persistence spec in JSR 220, in a year or so.

"He must be a king, He hasn’t got (expletive deleted) all over him."

Which brings me to the main point. Did you ever wonder what happened to the drivers of that cart? I mean, they’ve got to wheel this thing through all of the death and the germs, and get death splashed all over them. So here’s the real question. How many bodies can you safely handle before you’re effectively a walking corpse? This is why I think that the JCP executive committee will accept JSR 243 at the next vote. If they don’t, they lose credibility, and the confidence of the community that they’re trying to support. And ultimately, that path will lead to death.

"Bring out your dead!"

Time, wisdom and AOP

I'm teaching a programming symposium on most weekends called nofluffjuststuff. I've had the opportunity to attend some excellent classes by my peers. One of my favorite was given by Nicholas Lesiecki, on using AOP in main stream projects. He contends that AOP is here, ready for prime-time today. He provided some persuasive examples of how his team used AOP in real-world projects to solve crosscutting problems. (If you ever get the chance to hear him speak, I'd recommend it.) I've long said that we're not ready as an industry to move to AOP, and others share that view. Why the disconnect?

In another session, Dave Thomas (Pragmatic Dave) spoke about the learning patterns of programmers as they make the journey from novice to expert. I won't give away the talk, but the gist is that as we grow as developers, we learn in different ways, and progress from thinking in steps to thinking abstractly. We can increasingly put experience in context, and use the experience of others. I agree with this premise.

Here's my leap of insight. I think that we, as an industry, need to move through a very similar progression before we move on to a new programming paradigm. I think that we need to build that collective wisdom that only time and experience can bring. Sure, we need to succeed, and fly high. But we also need to crash a few times, and have the time to collectively pick through the wreckage and understand what's gone wrong. We need to establish how far we can push AOP (like we needed to learn how far to push inheritance.) We need to understand what constructs work (like programming to interfaces) and those that might not (like intercepting property accesses, or introductions, or advising an aspect.) How do we package? How will an approach hold up over time? How easy is it to maintain? How do we have a visual clue that something is advised? Do we need a clue?

Here's the thing. We've got 40 years of history to study the emergence of new paradigms. We can look in the rear view mirror and understand the same process for object technology, or structured programming, or high level languages. From a distance, it always looks like we move forward in surges, and stay stagnent for decades. It's not really that way, though. If you take a closer look, you can see the individual tiny little surges when we try slices of a new paradigm before we actually get it right. For example, a few people succeeded with SmallTalk, but the mainstream could not make it work. We were never able to make it succeed on a broader scale, maybe because it was too alien, and maybe because it was too tightly coupled to the smalltalk environments. But others tried to make objects fly in limited ways, like Ada and encapsulation, or like COM components and aggregation. It finally took an adaptation of a procedural language, C to C++, to give us a safe environment. C++ was safe because you could write oo code, and retreat to procedural code when you needed to. Sure, most of us wound up writing procedural code, but with the combined experience and community, we were finally ready for objects when Java burst onto the scene.

So my premise is that we need to look for ways to use AOP with training wheels. We'll see limited techniques that simulate AOP behavior, like interceptors. We'll see frameworks that let you configure prepackaged AOP services, like Spring. With technologies like these, we'll be able to use limited AOP power, and get some limited benefit. All of this time, we can more safely collect the wisdom that will make it possible to push AOP from small, expert-laden successful projects to the mainstream.

It's all about collecting wisdom.

Spring and the English Archer

2004 is a year of revelation for me. Better, Faster, Lighter Java was a fun book to write, and I learned tremendously in writing it. A closer involvement in the Spring project, and in the Java persistence community, also led to similar discoveries for me. It’s humbling to evolve my thought process in this very public forum, and thanks for sharing the ride. In this blog, I’m going to ramble a little bit. I’d like to draw some analogies to what I think is going on right now in the Java community.

In recent days, I've been reading Bernard Cornwell's Archer series. It's a book on historical fiction. I've read with some fascination the impact of the English archer on the battlefields in the 100 years wars. The bows were 6 feet long, and they took 100 pounds of pressure to draw. To wield such an incredible weapon, archers trained from childhood. The arrows were three feet long, and exerted enough force to pierce the thickest plate armor. They had great range. While they couldn’t fire as far as a crossbow, six to seven arrows could be fired for every one crossbow bolt.

No one seems to know why the English were able to employ archers on the battlefield in such great numbers, while other countries were unable to leverage this weapon. We just know that it changed battlefields, and in some ways, the course of history itself. Of course, we’ve come to call tools like this one disruptive technologies.

Throughout history, we’ve seen many different disruptive technologies: the printing press, cars, trains and computers. If you look at this industry, we’ve also seen other disruptive technologies: personal computers, the Internet, Windows and Java all changed the way that we use computers in fundamental ways. On a smaller scale, some programming paradigms are also disruptive. I believe that new programming models emerge because the old ways aren’t powerful enough anymore.

Think about a typical problem these days. Many of us try to build an application, with a user interface that can work on most of the computers in the world, and communicate with thousands of disparate computers, all in seconds. We tie these seamlessly to databases or other resource tiers, and can even do distributed transactions between them. But that’s not enough. As the programming problems get more complex (and they are), we continue to need to raise the bar. I think that we’re going to see aspect oriented programming in the main stream. It will probably not happen as soon as some expect, and it may prompt a completely new language from an unexpected source, but when it happens, it will be pervasive. In other cases, disruptive revolution comes from what you do, rather than what you use.

As an extreme sports adventurer, I can relate. When we learned to run waterfalls with more speed and at an angle, the ski jump, and later the boof move, was born. These moves let kayakers separate themselves from the vertical water of a large waterfall, and at the same time, dangerous hydraulics below such beasts. We could then run much more extreme rapids with less effort, danger and skill. As a result of these techniques and those like them, the popularity of the sport is exploding. As a weekend extremist, I’ve run a waterfall that were considered unrunnable just fifteen years ago. It was the technique, more than the kayaks, that changed, but new kayaks emerged to take better advantage, much like AOP is growing and maturing without an ideal language.

Dependency injection is leading to such a disruptive revolution. I think it’s leveling the playing field between smaller open source teams and the big J2EE vendor, such that open source projects like Spring can compete and in many ways, surpass, the software that’s coming out of the big container vendors. Spring, which already lets you do declarative transactions with objects that can be deployed outside of the container, just announced support for JMS, and will follow quickly with support of JMX. They’re integrating AspectJ. But what’s amazing to me is that Spring is still very clean and modular.

Dependency injection is disruptive because it’s simple, and it brings elegance and clarity to a design without oversimplifying an application. This weapon, though, does not need training from childhood. It requires a little restructuring of what you already know, and a whole lot of common sense. From clarity and simplicity comes better structure. From better structure comes taller towers, in the form of applications with more power and flexibility than we’ve been able to achieve in other ways. This much is clear to me now.

I see Spring as perhaps the fundamental driver behind dependency injection (it’s the lightweight container with the broadest market acceptance and momentum). In an earlier blog, I also mentioned that Spring is a good way to introduce AOP into the mainstream in a safer, more limited way. That’s why you’re seeing me bet more and more of my career on it. It’s disruptive. It gives me more leverage and power than I’ve ever had before.

Good middleware

Today, I hopped onto my mountain bike and had a great ride. Even though it was hot, the play of the trail over the hills was beautiful to behold. It had just enough down to let me recharge my legs for the next technical climb. It had sections that stretched me technically and scared me just enough, and sections that let me turn my brain off and just cruise. I got to thinking that it was all about me. I was in a zone. But without a good trail, I couldn’t have felt that rush or satisfaction. And then I started to get this great metaphor…and promptly crashed. Spectacular crash; soft landing; can’t complain.

Back to the metaphor. A good trail sits in the background, and if it’s doing its job, you know it’s there, but will never appreciate it as much as you should. And until the last year, I’d been noticing my middleware way too much lately. In a response to my first blog, I told you that I’d have the most boring blog on java.net. I’d have a single-minded vision of simplicity and productivity. I hope that I’ve remained true to that promise. Lately, I’ve been pretty vocal about EJB, lightweight containers and persistence frameworks. There’s a good reason for this. If I work hard to help establish standards that I believe make sense, it will eventually make my life easier, and my trail will fade into the background. Instead of working within the JCP, I’ve been working primarily in the court of public opinion. After all, we, the Java consumers, will ultimately have the final vote.

In fact, that’s the reason that Justin and I wrote Better, Faster, Lighter Java. I’d considered writing a book about Spring or Hibernate or even lightweight containers, but I sensed that it may be time instead to make a statement about lightweight development. Most of the people that read java.net on a daily basis already know about lightweight containers and AOP, and many like and use agile methods. But most Java developers haven’t got a clue about lightweight development if their vendor isn’t telling them about it. That’s my intended audience. To this end, I’d like to step back and talk about the principles that I believe are important for good middleware.

1. Good middleware is simple. One of the big reasons for the success of web-based programming is the simplicity of the model. You’re seeing a comeback of ORM technologies because they’re getting easier to use. And you’re seeing the community at large reject technologies that are not simple. Beauty, utility, and simplicity are all closely related. Effectively layered simplicity is the secret to good design.
2. Good middleware allows more transparency. By this, I mean that good middleware lets you hide services. It’s very important to be able to write a transparent model, without being concerned about persistence or transactions or security. This is why you see so much written about AOP, JDO, Hibernate, declarative transactions, and containers in general. They lay the burden of services at the feet of the middleware. Transparent code is far easier to understand.
3. Good middleware is easy to change and extend. Investments in middleware are inherently risky. Those who lead the market today may not be in two years. You need to be able to configure a variety of extensions. You also need to be able to swap out your services with minimal pain. That’s why you see added emphasis on things like reflection, class loading and configuration. It’s hard to be extensible without those tools. Standards and popularity play a huge role here. That’s often ironic, because popular frameworks and developers often resist standardization.
4. Good middleware is testable. Our leadership is reading the same books, and talking to the same consultants. The day of the large testing organization is over. That burden is increasingly falling on the every-day developer. Further, outsourcing is putting greater productivity requirements on each of us. If you can’t automate your testing, it’s not going to get done. You simply can’t afford frameworks that get in the way of your testing effort.
5. Good middleware makes you more productive. Great tools give you leverage. There’s no other good reason to use middleware. Otherwise, we’d all write our own.
6. Good middleware is safe. If you can’t depend on it for the long haul, it’s not good middleware. There’s no substitute for good management at the top of an organization. That’s why I tend to place such a high premium on the relationships with the people at the top levels of products and projects that I support. I’ve got tremendous confidence that a good management can fix significant flaws in a product (like IBM and WebSphere), just as I’ve got every confidence that poor management can torpedo any temporary competitive advantage.

If you want to ramp up on the lightweight movement, you might check out my book, but if you’re agreeing with everything in this blog, it’s probably beneath you. If you want to read authors that understand good middleware, start with Martin Fowler, Ted Neward, Stuart Halloway, and Rod Johnson. They know good middleware. If you want to see good middleware in action, start with products like Spring, Pico, Hibernate, Kodo, and Coherence. If you’re looking for good architectures and services that can move you in the right direction, look into inversion of control (or dependency injection), aspect oriented programming, transparent persistence, and declarative transactions.

As I picked up my bike and dusted myself off, I jumped back on the bike, and thought, “You’re still a good trail. This accident’s on me.”

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.

People of the elephant

The "elephant" article that java.net published last week was probably my favorite that I've ever written. Your responses made me work. After hundreds of blogs, e-mails, forums and phone calls, I'm still amazed that it struck such passionate feelings from my audience. (In an amusing twist of fate, Amazon chose that week to report that my new book, Better, Faster, Lighter Java, had not yet shipped, though they were taking orders. Rather than answer each blog in a boring tit-for-tat, I'm going to make more amuzing but practically useless gross generalizations. These are the groups of people that responded to my article.

• Some just like chicken better. Call this the tribe of chicken hunters. And I say, "More power to the chicken!" Some called me to ask me how to move from a diet from elephants to chicken. I learned that more and more people are learning to hunt chickens. Spring Chickens are now taking off and downloads are in overdrive. Hibernating chickens have never been stronger, and Kodo-chicken is having spikes in orders. Like their prey, some chicken hunters are not as always as bright. That’s OK. You don’t have to be to eat a chicken. Others are brilliant, including those that wrote the manifesto about changing our diets from elephant to chicken. Still others are purely pragmatic, seeing chicken as a way to save time, money and effort. Recognize this tribe from the elephant-sized footprints on their chest. Make them eat an elephant again at your own peril. I firmly believe that most of us will be chicken hunters soon.
• Some are grudgingly still working with elephants, but are having a difficult time. Let's call this the starving hunters. They stare longingly at chicken, but this tribe's betting everything on landing an elephant. They say that they just don’t have time to learn how to hunt chicken, and you can manage and deploy elephants on a much larger scale. They need some of the other parts of the elephant, too. Smugly, they ask, “Have you ever seen a chicken with a 14-foot tusk?”. Sure, they may take a casualty or two to the hunt, but the benefits outweigh the risks, and they believe that nothing but an elephant will save them, anyway. Recognize them by their battle scars, the racing eyes, and the vaguely frantic conversational style. Don't try to comfort them with alternatives. They probably do need the whole elephant. They may not know it yet, but they’ll probably be chicken hunters soon.
• Some don't care at all. They live in elephant hunting grounds with no other game, and are making the best of it. Call them the happy hunters. They’d adopt quickly if other tastier game moved in, or the elephants moved out. They know their station, and are pragmatically doing everything in their power to make elephant easier to eat. They actually like elephant. And it's been so long since they've eaten anything else that to them, it doesn't feel like eating an elephant. They speak a different language, and don't really care when someone says something bad about their elephants. They shop at SAMS for drums of chocolate sauce, and they use sophisticated elephant cannons that would pulverize other game. They don’t care; they’re hunting elephants. Recognize them by the radios that blare “Don’t worry, be happy,” and their nation's flag, that has a big grey border around a rising sun, with a motto around the perimeter that says "It tastes like chicken."
• Another group lives for all things elephant. Call this tribe the mighty elephant warriors. Their sworn enemy is the tribe of the chicken-hunter. To them, elephants are sacred. They are actually misunderstood, and they actually taste like manna from heaven. When I wrote my article, this tribe said that I was really just talking about EJB entity beans, or stateful session beans, or something else. They insist that if I'd really gotten to know their elephant, things would have turned out differently for me. But now, it’s too late; I’ve insulted their elephant. They get a mighty spiritual boost from elephant. They brag about being able to eat an elephant one bite at a time, but they’ve been gorging since adolescence. They've studied the hunt all of their adult lives, and can bring one down with a Swiss army knife and a toothpick. And it's infinitely easier than bringing down a dinosaur, the sacred beast of their ancestors. They may talk about hunting other game, but they will always come back to the elephant. They love everything about the elephant, and some of them actually want to outlaw elephant evolution. Of course, you may want to be a mighty elephant warrior, but most people that try to pass the initiation get trampled into the ground. A few survive the experience and join some other tribe. Recognize the elephant warriors by the "elfant-4-u" bumper stickers on their hummers.
• Another tribe just wants to pick a fight. Call them the cannibals. Don't try to recognize them. Just turn around and run.
• Then there are those that hunt other game. The biggest is the tribe of the whale hunter. They’re so intensely loyal that some are still trying to hunt whale in fresh waters! Some have heard distant tale of whale-lock-in, so all land-based hunters fear them. The visual-Shrimp hunters distain the whale hunters, and look back fondly on the shrimp-hunting days. You can recognize them easily, because they’re more of a cult than a tribe. Find the leader, and the billion whale hunters will be right behind.
• This tribe has actually never seen an elephant. Call them the cloud people. They are genetically superior, and have actually evolved to a higher plane. Cloud-people were already making advanced Smalltalk when chicken hunters learned that the first letter in chicken was C. They hunt unicorn. They’re completely brilliant, but often completely impractical. There are rumors that some of the cloud people actually started the tribe of the chicken-hunters, but that claim has never been proven. Few will ever be lucky enough to meet a cloud person. If you do, you'll recognize him by the eerie soft luminescent glow from their hair and skin from years of slow radiation.

And what do you think?

1. Is EJB an elephant? I'm not just talking about EJB persistence. Throw in the rest of it too. Is it easy enough to digest and understand? Can you buy it in parts, or would you even want to? Can you effectively decouple everything that you need to, so that you can eat it one bite at a time? Is it easy to teach, learn, maintain, and support? Above all, how does it compare to other solutions out there?
2. Are there other elephants out there that you're already dealing with today? Do you see any other large, unwieldy game, trotting around on the horizon that may grow to elephant-like proportions?
3. If you think that there are some real elephants lumbering out there, how will you choose to cope? Will you choose to go to a lightweight container? Will you radically switch programming paradigms, or move over to .NET? Will you instead just try to work harder and smarter?
4. What's your tribe? How would you characterize it?

Water for your rocket?

Have you seen the 2-liter water rockets? My wife Maggie and I recently bought a launcher to entertain our kids. We about killed ourselves drinking enough rootbeer to empty the rockets, and then headed to the park. My daughters Kayla and Julia stood slack jawed, staring alternately at the aqua missle and their crazed daddy.

You basically take a bike pump, a 2-liter soda bottle, and enough piping to tie the two together. Then, you add water (40% seems to be optimal based on the physics models), and "woosh". You can easily launch the thing 100-200 feet, but some water rockets with modifications have gone much higher than 1000. Pennies per launch. Water for fuel. Non-destructive. Lots of bang for your buck.

2003 and 2004 are turning into productive years for me. I want to introduce you to some of my new rocket fuel. I'm sure that you already know about the pyro rockets (Spring, Hibernate, O'reilly, and Martin Fowler). I want to tell you about the alternate fuels that helped to launch me for pennies. These are the lesser-known, or out-of-favor, people, products and ideas that have had a profound impact on me.

• Mike Clark. Mike is one of the most promising new authors in the J2EE space. People are starting to take notice. He's attracted to the most critical problems: automation, testing, productivity, performance. He knows how to communicate, and he's hooked up with a great new publisher (the Pragmatic Bookshelf), with fantastic editing support. It's hard to find good programmers, but he's a great one. It's harder to find people who can communicate, but he makes a great impression to his class rooms, his clients, and his partners. And he delivers, on time and under budget, every time. Mike worked with me to write Bitter EJB, and I used many of his ideas (and those of his publishers) to consolidate into Better, Faster, Lighter Java. His customers, students and readers alike rave. They're right. Read his stuff at clarkware.com.
• Justin Gehtland. Justin, quite simply, is the best co-author I've ever had. He's a zebra who looks equally good in white (Java) and black (.net). He's more popular in the .net space, but he's a very solid Java guy as well. He writes clean, simple code. Further, he knows process. He's got a well-grounded way of dealing with his clients. It's not fair to have such a nice guy, based on solid founding principles, who can also code, write, communicate, and see the big picture. Justin's biggest contribution to our community is that of a pragmatic, who understands what both Java and .net have to offer.
• Jay Zimmerman. Jay is a shrewd businessman who has quietly built an alternate conference to the JavaOnes of the world, and he's done it with a consistent vision and quality. Jay's biggest mark is on local Java communities. He's provided good speakers to Java User's groups, and has brought a high-quality symposium series to local communities not named San Francisco or New York. He's always looking for ways to improve. My favorite thing about Jay is that he always negotiates with a win-win attitude. Where JavaOne has become the voice of the big money, NoFluffJustStuff has become the voice of many important independent consultants. It's a fun conference, and it gives a voice to many who would not otherwise have one.

• Bloomba. If you know about Bloomba and have tried it, and you have a choice, you're probably using it. This e-mail client makes it easy to filter spam (90% plus hit rate for me), and do instant searches (less than a second for over 5000 emails....also searches content of attachments.) I used to spend a whole lot of time organizing into filters. Now, I just leave it all in one big box, and google, er, bloomba, for whatever I need.
• IDEA. I know, I know. It's already a popular tool. But I've rediscovered it after a brief time with Eclipse. It's simply the best refactoring IDE available. Sure, it's not free. But I'd gladly pay to help this great company produce great products. They get it, and refactoring has never been easier. I believe that it's healthy to buy great products, even when a slightly inferior open source alternative is available. It fuels innovation and progress.
• Kodo. I love Hibernate, and frequently recommend it, but for bigger, more sophisticated deployments, I usually recommend Kodo. It's fast, simple, and has some of the enterprise management tools that Hibernate lacks. Their CEO Neelan claims that they've never lost a performance benchmark since they released 3.0, and I believe him. I particularly like some of their performance management add-ons, and their mapping support is among the most flexible in the marketplace.
  
  SShhh. I heard it through the grape vine that the Spring project and SolarMetric are working together at the highest levels to provide first-class integration. I hope that this support is extended to cover JDO 2.0 generically.
• The Pragmatic Bookshelf. Dave Thomas and Andy Hunt are at it again. I've had a great experience with O'Reilly and my editor with Better, Faster, Ligher Java (Amazon got their shipment yesterday!), but you already know about them. I'd like to mention a pseudo-competing publisher in the Pragmatic Bookshelf. (O'reilly handles distribution for them.) They're writing smaller titles with ideas that last. They boil a subject down to the basics. I've loved the three books that I've seen. It's fundamental: we should weigh books on the quality of the ideas, not the quantity of pages. No more phone books!

• Test-driven development. This has been popular in the lab, but has taken a long time to take hold on production teams. Let me be clear. If you want to give your water rocket an extra boost, look to TDD. It's like pure H2O: raw simplicity and power. It forces cleaner designs and injects some automatic discipline. Further, since newer techniques like lightweight containers, AOP and dependency injection make it easier, it's time to give TDD a second look.
• Context inheritance. Spring's biggest impact to my life has been the improvement to testability. I can test out of the container, and I can stage small-scale integration tests, by providing a custom context for test cases. The problem is that this design philosophy leaves me with dual maintenance for my testcase contexts. Instead, I can use Spring's context inheritance to manage my testcases. The root class can use the production context, and every more specialized test case also has a more specialized context. Very interesting. I can then stub out a database witn an in-memory implementation for quick GUI tests, add specialized test data, or simply test a small subset of my overall system...all without undue repetition of contexts.

Water for your rocket. Always remember to launch from a safe distance. The fuel's more potent than you think.

On mountain biking and J2EE

Over this past weekend, I took the family to Durango. Most of the time, I was a good boy, and dutiful father. No near drownings on the Piedra or Animas. No mountain bike overnights down the Colorado trail. Not even a difficult hike. In fact, my body is in no condition to do any of these things...

But I did break away from the wife and kids for just long enough to do a 22-mile ride down Hermosa Creek. It was stunningly beautiful, and fun. I like to challenge myself. Sometimes, when I get on a bike, it's too hard to be fun. But this trail rocked. It pretty much followed the creek. For you geographically challenged readers, water runs downhill, and so does the trail. I screamed down the hill with beautiful Colorado weather, a babbling stream that's frisky with snow run-off, and the mountains around me on all sides. Spring flowers were everywhere.

That's kind of like the early years of Java. Programming was fun. No pointers, a JVM to take out the trash, simple servlets, easy access to the Internet--all downhill. After c++ and CORBA, life was good again. So the first five years of Java were like the first ten miles of the hike. Sure, I might have to hop off of the bike to hop over a little snow drift, or step through a mountain stream, but the trail was simple. It followed the creek. I wasn't encumbered by a map, didn't have to do excessive training, or buy any special equiptment. (In truth, I in fact rented a full suspension bike, but I'll take a little artistic license here and pretend I was on my companion's old school Trek bike without even a front shock.) Java was like that. Simple and unencumbered.

Then, things got fast. The trail got steeper and more serious. The trail left the creek floor for short stretches, and we followed the cliffs along the creek. It was still fun...we were going mostly downhill. And it was still fast. We were insanely productive. We covered huge stretches of trail between stops. But it was getting a little more dangerous. We followed unprotected cliffs on either side of the creek, just a foot to the right or left. Java was like that, too. Though we whine about the problems with the Java platform, we actually built a tremendous number of serious applications. We had enough success that the whole industry jumped onto the trail. But some people crashed. Still, the risk-reward ratio was right in line.

And then we hit the hill. The creek went through a canyon that didn't leave enough space for a trail, so the trail went up, and we followed. After the first 3/4 of a mile, I thought I was going to die. I was having to get off the bike for longer and longer stretches to walk through rocky terrain that was difficult to peddle. It was definitely a whole lot less fun. Truth be told, we could have actually cut the trip short, but the promise of the trail held us captive. I'll admit that my next trip down that trail may be in a kayak.

Finally, we get to the point. This is where Java is today. After EJB and XML Schema and Namespaces and WebServices, we're getting maxed out. Some of us will spend all of our energy and die, right there on the trail. Others will stare longingly at the creek below, and wonder if there's not a better way to get down the trail. AOP, anyone? Maybe something a little bit less dramatic, like one of the dynamically typed languages? Some will take that uber-programmer and muscle their way up the hill. Others will try to find a motor to slap onto the mountain bike, like MDA or other frameworks that try to do all of the heavy lifting.

This is a serious point in Java's history. How will we handle the hill? Will we handle the hill? Some say that we're beyond a point of no return, and the creek will stay in the gorge, fully independent of any trail. It's a tall mountain that the average Java programmer will never climb. Others say that we just have to grind it out, and there are better times ahead.

I think that we've got to simplify. My book, Better, Faster, Lighter Java, comes out in a week or so. It's at the printers, and you can order it today. My premise is that you can make it easier to scale the hills by lightening your load. Most applications are simple, and we don't need to go through artificial steps to complicate them.

The real trail tapered off, screamed down a hill, and went right back down to a natural rhythm of a little up, and a whole lot of down. I think that the Java community actually has a fork in the trail. On the left is a narrow but simple trail that goes back down to the creek. On the right is a huge, wide trail that will accept any type of bike, but it goes straight up. We can abandon the current trail, of heavyweight EJB, and full-blown J2EE containers, but we've got to lighten up. We can use the work that we've done, and the knowledge that we've accumulated, and ride the momentum down for a while. Some fantastic simple, yet sophisticated frameworks lead the way. Spring, Hibernate, Kodo JDO, and IDEA are a mix of open source and commercial products that do it right. Or, we could get overly ambitious, and die on the hill. Think Tomcat with Spring. Think Pico. Maybe some developers are strong enough to make it up that hill, and many will doubtlessly try.

I'm going to lighten up. I'm ready to go downhill again.

This work is licensed under a Creative Commons License.