I can't begin to express my sincerest appreciation for Dan and the great people at java.net (and O'Reilly) that made this such a great place to host my thoughts for so long. I've been reluctant to sever the ties. But I've come to the understanding that with the completion of From Java to Ruby, and the pending release of Rails Up and Running, using this space would not be fair to my Java audience, the java.net community, or me.
If you want to join me for a few laughs and new ideas, come to my private blog at Paddle Like Hell. If you're interested in Java ideas but would like to keep track of some interesting innovations in other languages, you can check out my Crossing Borders series at developerworks. You'll find six articles out there now, and we've extended the article series to include at least nine more. Many of them are Ruby-related, but I've also explored Erlang, Seaside, OCaml and a few others.
I want to express my profound thanks to those in the Java community that keep this fun, and push innovation. Thanks especially to Rod Johnson, Geert Bevin, Keith Donald, Patrick Linskey, Neelan Choksi, and the folks at No Fluff Just Stuff.
I'll still be around. I'm keeping a close eye on Spring, Rife, iBATIS, and EJB 3 persistence. (We've come a long way since the Elephant, just a few short years ago.) My blogging just needs a more diverse platform.
]]>But there's a subtle undertone in the Java community that's going back to the basics. You can see indications of this movement in Spring's JDBC framework, and Clinton Begin's iBATIS framework. I often teach about persistence frameworks, and the most rapidly growing group of developers is those that want to explore JDBC extensions, like iBATIS and Spring JDBC. You just don't always need full ORM. And full ORM can get you in trouble when you don't have the skills to pull it off, as Ted Neward so pungently described in his Vietnam blog (I'd link to it, but the site has been down for a while.)
I'm not saying that ORM is the EJB of the 2000s. I just want to propose the idea that one size doesn't fit all, and sometimes, it's a good idea to admit the database. Which brings me to Active Record.
Java really needs something like Active Record. For the expected case, you can just create your schema, and let Active Record discover your relationships. So a person object winds up looking like this:
class Person < ActiveRecord::Base
has_one :address
end
Ruby finds keys, foreign keys and table names through naming conventions (though you can override them if you want.) And you get all of the attributes created from scratch. Add a database column, and you don't have to change your code. Note that Ruby does something a little special here...it introduces attributes. With Java the experience would be different, but not impossible.
But the idea that my wrapping framework also eliminates repitition and extends through to relationships is very appealing to me. I can get down and dirty with SQL, or I can let the framework hide it from me. Admitting SQL is also one of the capabilities that's so attractive to iBATIS, and to a much lesser extent, Hibernate.
I also like the idea of reflecting through the model. I can ask any model class about an association on it. In this example, Person automatically gets an association called address. What table does it map to? I can say
Person.reflect_on_association(:address).active_record.table_name
I've built the basics for a simple report writer this way and it's nice. I can easily relate the table structure to the relationships of my object model. So to me, the lines between OR mapping and wrapping are blurring substancially.
Now throw in migrations. With a migration, you define a table in Ruby. Then, you have an .up method and a .down method. And you number the migrations so you can migrate schema and data in a single script. So here's a possible migration called 002_add_person.rb:
class AddPerson < ActiveRecord::Migration
def self.up
create_table "people" do |table|
table.column "first_name", :string, :limit => 50
table.column "last_name", :string, :limit => 50
table.column "email", :string, :limit => 100
table.column "company_id", :integer
table.column "address_id", :integer
end
end
def self.down
drop_table "people"
end
end
I can also add and drop columns and indexes. Active Record can take those migrations and translate them to SQL. So now, I'm pretty much independent of the underlying database version, if I want to be. And I can move up or down to any migration version:
rake migrate version=4
If I'm at 6, Rake will call 006*.down, and 005*.down. If I'm at 3, Rake will apply 004*.up. Migrations feel like Rails. I didn't expect to like them, but the idea just flows naturally.
Now, I'm not going to lie and say I'd be willing to jump through all kinds of hoops to try to map a legacy schema to a Rails project. I'd probably try to use Rails on Og, or Rails web services to a Java-backed project. But I do think that Active Record and Migrations solves it's target problem better than anything I've seen in the Java space.
So here's my point. Sometimes, it takes competition to force some interesting innovation. By using this stuff for a couple of weeks, my world view has changed. For a new project where I could define my own schema, or if I had an existing schema with object ids, I'd have a hard time moving back to the existing Java frameworks.
I'd love to see a strong Java implementation of Active Record. And I'd love to see a great generalized solution for migrations, wired into Ant. Sure, you can drive a screw in with a hammer. And sure, you can build a new schema with a mapping framework. But if you don't need to map, why bother? So the Java persistence community could learn a whole lot from Active Record. I'm a mapping bigot no more. Give me the best tool for the job.
]]>1) Lots of fans == successful framework == popular framework
Most framework developers want to be successful, so they need lots of fans. Sometimes, that means you've got to aggressively ride a wave that shouldn't be ridden, like XML everywhere, against your better judgement.
There are a whole lot of poor frameworks with lots of fans, like EJB 2.
2) Great framework != successful framework
The best framework developers start with good motivations. They want to improve the lives of their users in some way. But sometimes, that's not enough. There are lots of examples of great frameworks that never accumulated lots of fans. I've often promoted frameworks that did not win, even if I knew they might not win in the end. I love Rife; not sure if it will ever be successful on the order of Spring or EJB 3. A great framework needs to "cross the chasm" (see great marketing book by Moore), moving beyond early adopters to pragmatic everyday developers, to be a successful framework. Java crossed the chasm; Smalltalk didn't.
Some frameworks have great technology, but never experience broad success.
3) Great framework != successful programmer
This is the first tough one. You can pick a good framework, and get burned. Stagnation and momentum are important. The best horse doesn't always win the race. The problem is that the losers may finish second, or collapse so you're trampled by the eventual winner.
Good technologies sometimes fail spectacularly.
4) Popular framework + great framework == successful programmer.
This one is usually true. Rod Johnson and Juergen Hoeller didn't get hit by the same truck, and developers the world over are happy about that because they're much more productive. Spring, log4j, and Hibernate are a few examples, but there are hundreds. But here's the tough part. Great is subjective, greatness often fades, and popular is subjective in the early stages.
When you can choose great and popular, you should.
Breaking it down
So, there are a number of interesting issues for me as an independent consultant here.
- My radar comes on strong when someone aggressively speaks out against an acknowledged great framework, that is also rapidly gaining in popularity. I wonder, what's the motivation of the speaker?
- I often look for popular frameworks that for whatever reasons are not great frameworks in certain contexts. The reason is clear: I can provide a whole lot of value to a whole lot of people that are possibly using something that's just plain wrong or out of context. BFLJ, Beyond Java, Bitter Java, and Bitter EJB were all books on this theme. To a lesser extent, Spring ADN was on that theme too, as an extension of BFLJ.
- If you want to spot the great frameworks that will also someday be great, popular frameworks, you need to be studying both technology and marketing.
- I'll be coming out more aggressively for Ruby on Rails in the next couple of months, because it is clear to me that RoR will be a popular, great framework based on the steepness of the adoption curve. RoR will cross the chasm. The leading edge of a disruptive technology is a good place to be. I can help a few customers secure a competitive advantage, and I can help my customers deliver more value and charge more money for what they do. That's important for both my customers and me in an era of globalization.
- I think Spring is another good place to be. Spring is a popular, great framework. Spring has crossed the chasm.
- I think Java's greatness is fading, as all great programming languages fade. We simply accumulate new understanding. Java has crossed the chasm, but its greatness may be failing.
So the "fan syndrome" is complicated. Are you defending fading greatness, are you blindly supportive of popular but not great, or are you objectively identifying popular greatness? Time will tell.
]]>
Tuesday, August 11
I bought a new pet monkey. He’s got a mark on his chest in the shape of a coffee stain, so I call him Joe. Joe's not much to look at, but he's better than Sea Bus Bus. I’m going to sleep, but I’m a little worried about him, because he ate the computer. Hope he lives...
Wednesday, August 12
Joe can code! Maybe it has something to do with eating the computer. He can do so many of the things that Sea Bus Bus couldn’t do. Now, I don’t even have to go out to get the morning paper. Joe just hacks the Statesman site, and prints out all of the stories I want--even the ones that aren’t confirmed yet. On a whim, I walked him over to the file cabinet. It had a spider web hanging off of one of the handles. I smothered the whole thing with gravy and show it to Joe. He ate that too. I hope it works. I wonder what he’ll do tomorrow...
Thursday, August 13
Joe is coding web-enabled database applications! Weird.. He’s about the size of a small chimp now, filling out nicely. Maybe I’ll be able to ride him like I did Sea Bus Bus soon. Now, the neighbors are coming over. They’re giving him their harder coding problems. I don’t care. I can’t keep him busy enough. He’s insatiable. The more I feed him, the better he codes. Today, I fed him sixteen pies full of tiny little apples (I call them applets), three shoeboxes of photographs, seventeen CDs, and my IPod. He’s doing multimedia now. I’m off to buy some more food...
Friday, August 14
I’m pissed. Some guy named William Portal snuck into my house and cloned Joe. He even photocopied my diary and fed his monkey clone the same stuff Joe’s eaten. I’ll just have Joe eat the local University’s legal library, tell him to type up a law suit, and go to bed. Maybe it will be worth a couple billion when the dust settles...
Saturday, August 15
I can’t feed him anymore, which is OK because all of the neighbors are feeding him stuff now. Joe eats it all--I've seen a car part (I think it was a set of struts), a swing set, a cobra, a sleeping bear, my obese boss named John, and the artificial grass at Texas Stadium. I’m off to post some FUD on The Server Side about Pee Wee’s coding hamster...
Sunday, August 16
Today was Take your Pet to Work Day. You know I had to bring Joe. On the way, I stopped at Taco Bell to get Joe fifty two bean burritos and a giant cup of Starbucks coffee (he could only drink one large). I pulled up to the building, and Joe ate the whole company. I rationalized “It’s OK…I’ve been meaning to quit. Joe can support me.” Joe’s now the size of a gorilla. He’s happy, but his stomach is rumbling. Maybe the queasiness has something to do with mixing the whole enterprise, the cup of coffee, and all of those beans. Oh, well. He’s eaten worse. I’m off to buy a bigger house...
Monday, August 17
I’m a little concerned about Joe. He screwed up his first program. It was an easy problem, too--just an on-line pet store. I noticed his fingers are getting too fat. His programs work, but his fat fingers make him type way too many characters. The neighbors are getting restless too. Joe’s now got a back log of applications. I’m off to run some benchmarks for Pet Shop...
Tuesday, August 18
This thing is getting out of hand. I discovered that a group of companies has been meeting to decide what to feed Joe, but he’s my pet. I don’t dare complain, because I can’t feed him anymore. They wanted him to think in a more structured way, so they fed him the largest law firm in the world--X-pert Mega Legal. I don’t know what to think about that. Joe’s even had toilet water before, but lawyers? You are what you eat, you know? I’m off to buy a bigger house...
Wednesday, August 19
Joe and I are having problems. I told him he needs to go on a diet--he'd be better and faster if he were just a little lighter. We fought a little while. I showed him a picture of an elephant, and he took it a little too personally, you know? I cried, he cried, and we made up. He agreed to exercise and get an enema this Spring. Joe had his customary four-hour dinner, worked for five minutes on his backlog, and went to bed. His productivity has gone to pot. I haven’t been sleeping well, because Joe has been looking at me with these hungry eyes. I’m off to outsource some of Joe’s application back log to Kumar Botzwani’s pet Bengal Tiger down the street...
Thursday, August 20
I’ve had it. I can’t buy any more new houses. There aren’t any houses big enough to satisfy Joe. I’ve interviewed new pets. The coding dung beatle named Prince Harold Phillip is plenty fast, but no one wants to touch the keyboard when he’s done. Larry, the coding oyster, is fast but he codes all of his variable names and comments each in a different language, so I can’t understand his programs. My wife won’t even let the coding python into the house. I’m off to see a psychiatrist...
Friday, August 21
A puppy! What an adorable little puppy! Here, Ruby, Ruby..]]>
Still, there never should have been a second vote. The JCP executive committee members need to think in terms of voting for the good of the community, rather than for self interests, 100 percent of the time. This vote goes a little way toward repairing confidence in the Java community process, and that's a GOOD THING.
]]>I’ve got a little kid inside me, but not when it comes to Java tools and frameworks. It takes a lot to get me to adopt a new framework. But sometimes, when friends that I trust are playing with something, I’ll pick it up too. Erik Hatcher, Stuart Halloway and Dave Thomas are very good at distilling the buzz, and separating out what’s important. So I decided to give Ruby on Rails a try. Rails founder David Heinemeier Hansson claims gaudy, plastic-like 10x productivity gains over Java. I’ve been skeptical, and I’m not alone.
Around 1:00 PM, the first toy breaks, and the joyous laughter turns into heart-wrenching doom. After a little comfort and a lot of psychology, we get the kids to move onto something else. In truth, not many toys will survive the first couple of months after Christmas.
David Geary summed up the feelings of the Java community nicely. Rails may be productive out of the gate. But it’s sure to wither under the load of enterprise development. After all, Rails has a few obvious flaws: domain objects must inherit from a common persistent base class, the templating technology does look a whole like the embedded Java that failed for this community, and Ruby is probably not as fast as Java. Further, early in the Rails development process, developers rely heavily on scaffolding to get things off of the ground quickly. That might lead to immediate productivity, but the gains will surely dwindle over time as the scaffolding is replaced.
After a couple of months beyond Christmas, the best toys emerge. They are built to last, and have enough flexibility to keep up with the active and fickle imagination of a kid.
But I love Ruby. And I think Rails has potential. The experience starts when I want to download Rails and add it to my Ruby installation. I type “gem install rails.” And that’s it. Ruby goes and gets the latest installation, and also pulls down the dependencies that I need. Very slick. Next, I want to get plugged into Rails best practices. I want to use the right directory structure, and build the first sample applications in the right way. I read a little bit, and then type “rails messages” to create my application structure. Similarly, I can generate and scaffold a basic application, with model, view and controller layers, to do the basic CRUD operations on a database. The process takes 15 minutes. There’s no setup for the web server. I don’t need to live with the scaffolding until the end of time, but I generally find that I’ll use some of the scaffolding methods with very little change. I’ve not used Rails for a production application yet, but I can imagine that it would let me get a simple user interface flow in front of my customer in a hurry. For that reason, I used to build “ugly pages” which could later be customized by a designer. So, immediately, there’s a lot to like. But is it a toy?
Invariably, a relative will give a movie or toy to my kids that I just don’t want in the house. I don’t like Barney, or Barbie, and never have. My girls have quit asking for them. Won’t work. So I’m a jerk, but a happy jerk.
So here’s the rub. Is Ruby a toy? And if not, is it fundamentally sound? Many rapid development environments break down because they might provide more productivity than their basic languages, but they also limit the power of the language. VisualBasic is famous for letting you build the first 80% of an application quickly. It’s that last 20% that will kill you.
I don’t think Rails will suffer from this problem, to the same degree. You can completely replace the view, controller and model layers for Rails. The difference between Rails and alternatives is that you can live within the scaffolding in the mean time, and then iteratively adopt it for your use. There are things that will keep me from using Rails on some projects. Most of them have to do with limiting technology for a given problem, like the lack of OR mapping for an existing schema. (I think Hibernate and Kodo JDO both kill ActiveRecord if the schema doesn’t match the model, or if the two are expected to evolve independently.) I don’t think that the Rails developers have completely thought through the visual component architecture, in a way that say Tapestry developers have for layered user interfaces.
In fact, the best “toys” often turn out not to be, well, toys. One kid loves her necklace, and the other loves her mountain bike. Big and beautiful books are often hits. To survive the first couple of months, a toy must be good. It usually is beautiful, simple, and has a little bit of magic to it.
Which brings me back to Ruby on Rails. It’s got that magic. I’ll just give you a little taste. When you’re mapping a Java class to a schema, you must often type the name of a property five times. !!!FIVE TIMES!!! Count them. Three in the bean: the getter, the setter, the instance variable. One in the schema: the field. Two in the mapping: the property, and the column. In Ruby, you type it once. Reflection and inspection of the database handle the rest. You use intelligent defaults and naming conventions to handle the rest. You can always override differences, but you don’t have to. Or take the mark up tags. They look like Ruby. Heck, they are ruby. That beats the scripting that we usually put into HTML, in the form of JSP tags.
So I’m not completely convinced, but I do think there’s something here. I’ll certainly try to get paid to do Ruby in the near future. But I do think that Ruby has the magic that great solutions have. And I think that part of that magic will never translate to Java.
My kid looks into the toy box. Will she reach for the toy that she got a few short months ago, over Christmas? I really don’t care. It depends purely on the game that she wants to play.
And that’s where Java developers often come up short. We’ve got a golden hammer. It’s the ultimate golden hammer. It’s the programming language itself. I’m not going to pretend that anyone would ever use Rails for everything. But think of the number of applications that you build that do nothing but put a big web front end on top of a persistent model. That’s a huge part of what we do. If Ruby and Rails can make you that much more productive, and if it solves the problem, why wouldn’t you?
]]>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!"
]]>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.
]]>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.
]]>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.
]]>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:
And a little heresy is good for Java. Thank you, Paul.
]]>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.
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.”
]]>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
Technology
Architecture
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.
]]>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.
]]>I was on the Piedra River in Colorado. My long-time kayaking partner Mike Oehrtman and I had met a couple of locals to guide us through a river that we assumed would be fun enough to get us in trouble, but not too fun for our own good. We watched them put in and shred the river. They played every little hole and toyed around with monster waterfalls. They made it look easy.
But through humorously tragic miscommunication, I found myself on a section of the river that was over my head, both literally and metaphorically. I was not where I thought I was, and my skills could not cope with the power or steepness of the river. After rounding the corner, I meandered into a violent eight-foot twisting drop. It hammered me. I flipped, tried to roll, panicked, bailed, swam. In fact, I swam over waterfalls and under downed trees through frigid waters for nearly a mile, in an incident that should have killed me. After scraping myself out of the river and getting myself and my gear collected, I had barely put my paddle in the water when I screwed up yet again. Wet paddle. Hear roar. Make mistake. Flip. Blow roll. Blow another roll. Panic. Curse underwater. Choke. Bail out. Swim. All in all, I swam four times that day. I felt like Bill Murray in Ground Hog Day. (He lived the same bad day over and over.) Most of the time, I couldn’t tell what mistake that I made to get myself into trouble in the first place. I’d found a river too big for me to run. I’d hit the wall.
Some Java developers that I know feel a little like that right now. They’ve hit the wall. It’s ground-hog day all over again. Get excited. Learn a monolithic API. Start to build it. Make design mistakes. Dig hole. Make mess. Curse. Work overtime. Scratch and claw. Find silver bullet. Lather, rinse, and repeat. While it was great at one time, this object technology doesn’t seem so easy any more.
Enter Ground Hog Day on a grander scale. Those of you who are old enough to remember have seen this before. A long time ago, when we thought we’d taken procedural programming as far as it would go, we hit that unrunnable rapid. People wrote books like the Mythical Man Month and Death March. So we innovated. Object oriented technology was born. We started playing with it in the 1970s, with Small Talk. A few joined the band wagon, and used the technology to good effect. They are like the guides that led Mike and I to the dangerous river. And they had fun, and were incredibly productive. And like Mike and I, other lesser equipped paddlers in the industry followed enthusiastically, but they were in over their head. And they crashed and burned. They heard the roar (inheritance? CORBA? #define?) And they flipped, tried to recover, and swam. Some wailed, “This is truly a river that is too mighty for the layman to run. Let us build a sign, and a wall, to keep the public safely out. Let there be no more good people drown here.”
But it turns out that the river unrunnable after all. In fact, while we were sucking that cold water through our nose, and scratching our way to the shore, we were learning. Our universities taught. Gurus published. We read.
And some smart vendors paid attention, and introduced simpler technologies, like objects with training wheels. COM gave us components without inheritance. The defense industry gave us Ada, or encapsulation without a full-blown object model. C++ gave us the additional object oriented semantics, but left the procedural stuff in tact, so the effect was like a C plus plus, minus minus.
At the time, it looked like we’d hit the wall. These “solutions” often looked like they were doing more harm than good. But we were learning, and absorbing. The collective psyche of the masses was moving, so when we were ready for objects, they not only met modest success, they exploded on the scene with Java. The world was ready for more, and Sun got the product and the timing right. The rest is history.
And that, finally, brings me to the point. We’re in a similar place today. The early guides are putting in on the roaring river, and their kayaks have AOP (Aspect Oriented Programming) all over them. And a few of us are going to foolishly follow them down the river, and maybe even get killed. We’ll hear that AOP really isn’t a seventeen-foot rubber raft that is immune to capsize. But what happens next? Can that particular river be run? I, for one, think so.
You can see the early stages of the first backlash. In fact, if you try to turn everything into an aspect, you’ll crash. Certain aspects are hard to understand. We need to understand implications of performance, and learn to test performance. Some of it seems too much like black magic. And some are saying that maybe AOP is the wrong model.
But a few people are bringing AOP ideas into the main stream. They are giving you AOP with training wheels (pontoons?). JBoss has publicized the idea of interception in an EJB container. Perhaps a better example is the Spring framework, where you can consume AOP services. So, you’re starting to see people talk about the important concepts in AOP, like transparency, and independent services, and generalization of an important problem, and cross-cutting concerns. In fact, in my book (Better, Faster, Lighter Java), I don’t talk much about AOP, because I don’t think that most of us are ready. Instead, I talk about basic principles that we can borrow from AOP, and apply today. And I think I’ve struck a chord that’s ringing true. Today, my book was #3 on the list of JavaOne best sellers.
If you think about it, those ideas are all around us. Spring is a way to consume aspects in Java. JDO is a persistence aspect. JBoss, Pico, Keel, JSF, and many others let you use IOC in meaningful ways. True, these frameworks will not, in and of themselves, introduce the full power of AOP. But don’t view this as the end. While it may seem like we’ve hit that unrunnable rapid, we’re moving forward. We’re learning.
And that’s where I think we are today. We’re learning, and we’re getting ready to conquer that rapid that’s seen experts, but has to date been unrunnable by ordinary Joes, like me. And that’s what I’m looking for at JavaOne. I want little steps toward the next paradigm. I want chicken instead of elephant. Simplicity. Transparency. Interception. Attachable services. Inversion of control. Testability. I’ll find it in pockets—at JetBrains with IDEA; Kodo-Spring integration at the SolarMetric booth (where I present on Wednesday at 2); in the experiences of the expert guides; in BOF (Birds-of a-Feather) sessions; in the bars. But for the most part, I don’t think it’s going to happen at the keynotes, or in the big booths. This year, the action’s with the little guy.
So fast-forward to 2002. After another mistake in judgment, I found myself on a flooded creek, once again, far more difficult than any I’d ever encountered. That day, one expert kayaker died, and two were rescued by helicopter. I shouldn’t have been out there. But I had learned enough, on the Piedra and other places. I coped, and survived, and even thrived. I can’t say that I’ll ever jump on that creek in flood. I may not even try my luck on the Piedra again: I’m getting a little old for that stuff. But on that day, the knowledge meant survival. Today, for Java, it means the same thing.
]]>