 |
|
 |
 |
|
|
 
Bruce Tate's BlogSpring and the English ArcherPosted by batate on July 30, 2004 at 02:55 AM | Comments (9)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. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
