Bruce Tate's Blog

Community Archives

Thanks...

java.net has been good to me for all of these years, but it's time for a change. I'm moving my blog to Paddle Like Hell.

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.

Kudos to JCP executive committee.

JDO passes, without no votes. Of course, the abstain votes from IBM, Oracle and JBoss are thinly veiled no-votes. Still, when you combine this vote with those for the combined persistence API that effectively breaks persistence out of EJB 3, we're likely to have much better persistence alternatives in the Java space, and sooner rather than later.

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.

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?

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.