Dinosaurs Can Take the Pain

There has been much discussion on whether Java programmers are becoming dinosaurs, on an evolutionary dead end and overtaken by more nimble mammals. Bruce Tate has long abandoned Java for greener (or redder) pastures. Bruce Eckel has embraced Flex , Bill Venners favors Scala. Python is making inroads in college curricula. What is a Java programmer to do? In this blog, I argue that we need to focus on less on syntax and more on the pain points of Java programming.

Pain vs. Discomfort

Let us go back in time, to 1995, when Java first appeared. We were programming in C++, Visual Basic, and “fourth generation” languages such as FoxPro. Since I was a C++ programmer, I remember exactly what my pain points were:

Memory management was intensely painful. One bad pointer could wreck your entire program in mysterious ways and condemn you to many days in debugging hell. Writing a GUI that accessed a database in C++ was (and is) like eating soup with a fork.

When Java came along, I got garbage collection and an API that let me do stuff. I was sold.

I was (and am) surprised when people tell me how they hated operator overloading and multiple inheritance in C++. In the grand scheme of things, these caused me discomfort but not agonizing pain.

Deckchairs on the Titanic?

Now let's look at C++ in 2008. It is still alive and kicking. There is an effort to make sweeping changes in the language and library: templates on steroids, “smart” pointers, multithreading support, even optional garbage collection. The folks who work on that stuff eagerly discuss the merits of the various proposals while the rest of the world looks on with wonder. Even if all these efforts come to fruition, can you imagine banging out a web application in C++? C++ has become a niche language, but I talk to many C++ programmers who live in total denial about that fact.

How about Java? Are we living in denial? Are our discussions about closures simply arguments on how to rearrange the deck chairs on the Titanic? What about the point of view that Java should be “stabilized”? Does that mean “fossilized”?

I think that there has been way too much discussion whether this or that proposed language feature is elegant, ugly, or confusing. Java, its APIs, and its development environment are tools to produce software. Where there is too much pain, we should evolve to address the pain, or the rest of the world will look on with wonder about our silly syntax discussions.

It is futile to hope for stability. There always will be pain since we are bound to take any technology and push it beyond its limits.

My Pain in Java

Here I am, a Java programmer in 2008, and I know perfectly well what I hate.

From an emotional point of view, the boilerplate is what I feel every day. Every time I write a stupid getter/setter, an event listener with that wretched inner class syntax, or another long-winded type declaration that the compiler could perfectly well infer, I cringe. But that isn't enough for me to change languages. It is discomfort, not pain.

But when I embark on another web application (which is what I should be doing this morning instead of writing this blog), I groan. I use JSF in the forlorn hope that someone else has given me components that make me not worry about AJAX and GET vs. POST, all of which have nothing to do with the problem that I want to solve. But then I read descriptions such as this or this, and I despair. If I have to paste random pieces of code to make things work, I just know I'll be hosed when things don't work.

Come on, folks, When I write a web application, I want to be able to say "This is the common layout of my pages, give me a standard login screen, I want a menu here, and fill that table with those database values, but add a column with buttons..." I can do it in JSF, but it is like eating soup with a fork.

Why is it that Sun can't give me a decent web framework? Is it a shortcoming of the Java language? Or crummy API design? Rails uses the metaobject protocol to good effect in Active Record, but as it turns out, that isn't my problem. JPA works ok for me. The rest of Rails doesn't attract me—I want components, not RHTML files. I think in this case, the Java language is sufficiently powerful, but we are hobbled by backwards compatibility with JSP and JSF, both of which are simultaneously complex and underpowered. Or could a language enhancement such as continuations make web programming dramatically easier? If so, why does Rails get all the buzz and not Seaside?

Finally, concurrency scares me. I am not smart enough to write a nontrivial concurrent program where I can say with confidence that it won't ever deadlock and that it won't have any race conditions. Just like I was not smart enough to write a nontrivial C++ program where I could say with confidence that it won't ever leak or corrupt memory. So far, I just stick my head in the sand. But as multicore becomes more prevalent, that won't work. Do we need a language change or a better API, such as actors in Scala?

I'll suffer through the boilerplate discomfort, but if something doesn't happen with web applications and concurrency, I'll eventually bail. Dinosaurs can endure pain, but I can't.

What are your pain points? Can the Java ecosystem change to address them?