Bruce Tate's Blog

July 2004 Archives

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.

A strange car

I was shopping for another car. I pulled up in front of the greasy car lot, wanting to know why the vintage cars were so popular. When I found the place, it seemed more like a shady garage than a dealership, and the salesman certainly reinforced that image. He had the distinct smell of transmission oil in his hair, and grime under the nails of his extended hand. I took it, and told him to show me what all of the buzz was about. Sizing me up, he walked me over to a replica of the General Lee, a famous car that was the centerpiece of a 1970’s sitcom called called “The Dukes of Hazard.”

Rather than show me the styling or the interior, Jimbo reached through the window, and popped the hood open. He then showed me the engine. I’ve done a little tinkering in my time, but I didn’t recognize a single stock component. I pointed to a gizmo that I did not recognize, and he told me that it was an XE7 turbo, or something like that. I barely even knew what a turbo charger was, so I may have the letters wrong. Jimbo explained that the device would give me a 2% boost in performance. I was wondering why every car would not want such a thing when Jimbo explained that “only cost” was that he had to let the oils in the turbo heat up while the car started, and cool down when it was done. I’d have to start the car 20 minutes before I started to use it, and leave it running 20 minutes after I was done.

Jimbo looked at his Frankenstein creation with pride, explaining that it took a lot of love and care to keep such a beast running, but it had never let him down. I wondered who exactly was qualified to work on such a creation. He carefully explained that keeping it running was no problem. I’d eventually learn my way around under the hood well enough to do my own maintenance, and in the mean time, there were six garages in Texas who could handle the key maintenance tasks. But Jimbo said that all of the enhancements made the car fast, even very fast. I couldn’t bear to tell him that I really just needed something to do what 90% of the cars in America do, just get me from place to place in traffic and over roads that would never let the car approach its full potential.

I asked if I could sit in it. Jimbo broke into his toothless wide grin and said sure, I could jump in...

Jump in? Ahhh…of course. The General Lee. The doors were welded shut. There were no movable doors. In fact, this General Lee had been built for a Gangsta Rapper, who had not taken delivery of the vehicle, so it had an upgrade: all windows were made of 3” bullet proof glass. Perfectly secure. You could open and close them through a customized remote control that would roll them down just enough for you to squeeze into the car.

I’ve got my share of guilty pleasures. And one of them is the Dukes of Hazard. I really wanted to like this car, so I put my reservations aside for a little while and climbed in. I asked if I could drive it. Jimbo said sure, I could put my name on the class list…

Class list? It took me a little while to switch gears from programmer mode, and it occurred to me that he was going to teach me how to drive this beast. And it might not be easy. In fact, Jimbo had a waiting list for his driving class. I looked at the dash board, and immediately understood. It looked like a commercial 747. Meanwhile, Jimbo was asking what’s not to like. It’s fast, reliable, secure…

There comes a time to end the madness, and I ended the madness, cutting the sales process short. I smiled, shook hands again with a grinning and greasy Jimbo, washed my hands, and then looked outside. There were hundreds of people lined up for the opportunity to buy this car. And later, I saw one of those people flying by me at 95 (in a 35 zone) in the General Lee. He met my eye, and shouted out the window, “Sucker!!!!”

The whole experience seemed vaguely familiar.

A little heresy

In Hackers and Painers, Paul Graham of Arc fame dishes out his share of heresy. He tackles social heresy (actively seek out heresy, schools are prisons). But it's the programming heresies that interest me most.

This guy really challenges you to think. He represents Lisp as the one true language (certainly, the most powerful.) He talks about the problems with Java. He discusses a start up founded on Lisp that was much more productive than their competition, and digs a little at the Java community by saying that he wasn't worried if his competitors were putting up job postings for Java guys.

The book certainly made me think. We're in the age of heresy. You can say things today that you couldn't say five years ago. Here are a few of my favorites:

• Stratic typing is an artificial safety net. Dynamic typing can make you much more productive.
• Checked exceptions may have been a mistake.
• OOP may actually hinder reuse. Layered software may be more important than OOP.
• Maybe the bigger vendors don't have it all figured out before they ship a product. (EJB, CORBA, etc.)

And a little heresy is good for Java. Thank you, Paul.

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.

This work is licensed under a Creative Commons License.