Dinosaurs Can Take the Pain
width="110" height="111" />There has been much discussion on whether Java
programmers are becoming dinosaurs, on an href="http://www.artima.com/weblogs/viewpost.jsp?thread=221903">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
Pain vs. Discomfort
width="98" height="122" />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
- Access to database and GUI features
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?
width="116" height="109" />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
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
- Boilerplate, boilerplate, boilerplate
- Web applications
style="margin-right: 1em; float: left;" width="114" height="117" />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 href="https://woodstock.dev.java.net/index.html">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 href="http://www.netbeans.org/kb/60/web/pagefragments.html">this or href="http://www.netbeans.org/kb/60/web/web-jpa.html">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 href="http://blog.rainer.eschen.name/2007/04/01/when-theres-bad-smell-in-your-jsf-tag-soup-due-to-facelets/">don't
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
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 href="http://www-128.ibm.com/developerworks/java/library/j-cb03216/">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?