Bruce Tate's Blog

February 2005 Archives

The toy?

It’s way too early in the morning, but the kids are tearing down the stairs, and making more noise than my aching head should tolerate. But it’s Christmas, so I do. They are drawn to the biggest, flashiest, plastic toys first, but my wife and I share a knowing smile. That will change.

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?

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!"

This work is licensed under a Creative Commons License.