Skip to main content

Dinosaurs Can Take the Pain

Posted by cayhorstmann on January 8, 2008 at 9:32 AM PST

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
programming.

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
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.

  • Boilerplate, boilerplate, boilerplate
  • Web applications
  • Concurrency

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
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 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?

Related Topics >>

Comments

Actually, the professors have the opposite issue with Java. For them, Java is too alive. They decry the fact that students can actually get useful work done with Java, just by taking a class here and a library there, instead of having to build everything from raw bits.


I was thinking the same thing, though they don't want you to be able to build everything from "raw bits" - that would be the case if they were using assembly rather than ADA. Instead, they want you to be able to quickly pick up the over-designed ADA features.

Java features are well designed, C++ features are misdesigned, and ADA features are overdesigned. So, of course a programmer who is used to well-designed features has trouble using the very same over-designed features.

I'm right there with you. I never felt very comfortable with Swing and friends, too much noise for simple clicks, forms and tables. Add a few decent extensions to the language (closures, first-class properties) to get rid of the most annoying boilerplate, and the fun is back in desktop programming!

Web apps are a different story. I've gone through this madness since the very beginning: CGI, Servlets, JSPs, Struts, Cocoon (oh Lord!), JSF, Facelets and whatnot. Exactly every approach ended up in a messy conglomerate of HTML/XML fragments/templates, Java classes here, JavaScript snippets there, HTTP in between, glued together by other scripting/binding/template-languages (JSP/JSF-EL, Velocity, XSL/XPath, ...), executed by a truckload of JARs in WEB-INF/lib and configured by XML descriptors dictating a gazillion of XML-namespaces which a semi-smart person like me can never memorize. (For a fully-featured rant I have to mention browser incompatibilities, character encoding hiccups, URL encoding/decoding pains and many other things I really never wanted to solve or even know about, but that's not the fault of the Java frameworks).

Nowadays I use GWT, which has all the shortcomings of Swing-like programming, but you know what: For the first time since years I enjoy web-programming again! I'm joyfully writing lots and lots of boilerplate for wiring my widgets to anonymous listeners, and I even pardon the Google folks for their clumsy RPC (boilerplate^2), because with GWT I have a simple and cohesive programming model for both the client/browser- and the server-side, based upon a single primary language: Java (granted, HTML, DOM, CSS and a little bit of JavaScript leaks through this abstraction, but I did expect that).

I agree with atripp, Templates + portability problems turned me from loving to hating C++ in a few months. At the time I used a lot operator overloading (I was doing a lot of geometrical transformations) but they also caused some headaches - today I consider them a pure danger. Multiple inheritance didn't hurt me, but at the time I went merely with spaghetti code, I learnt design later and today I'm totally for the composition over inheritance thing.

I agree Concurrency can be a real pain. Here are my "Pain Points" that run into most often.
  • Swing On/Off EDT management
  • Layout Managers
  • Quoted Strings + REGEX
Swing is an amazingly powerful API and the new scene graph is going to be really cool, but multi-threading + Swing can be a pain. The EDT forces one to program asynchronously. You spawn a SwingWorker, process long task, update GUI. Some things can't be done like that, say like spawning a background thread to sort the contents of a table model.

There is one place though that might be a good starting point for making things easier. Spawning a modal dialog. Somehow spawning a modal dialog halts the current processing on the EDT, launches a new window, continues to process events and yet returns execution to the line of code after the setVisible(). Could this mechanism be generalized into something reusable? That would be really handy.

Isn't it about time we had an easy to read layout manager? GUI designers come and GUI designers go but the code will always be there for as long as the application is supported. I can't think of any other place in Java where named parameters would make more sense. I put in a request to add a varargs version of add() to Component, but I don't think it's going to be included in 7. It has the possibility of helping to create simpler layout managers. (For the record I think MiG Layout is really nice, but the syntax in the strings is like a language of it's own)

Finally I'd really like to see some kind of syntax for absolute string literals. Meaning that there is no escaping necessary. Have you ever tried to put a \ into a regex? It's like 6 \'s. The change in the compiler is so trivial that I did it myself to OpenJDK and it works great. I'm not the only one to have done this and I know some other people actually submitted the change. Why don't we have this?

I agree whole-heartedly on the pain-points with web applications! What are your thoughts on Wicket? When I'm not at work (read when I'm not shackled by corporate tool control) I choose Wicket for all Java web app development. It just makes sense to me.

My Java pain points:
  • Boilerplate, especially for listeners
  • Clumsy and inconsistent swing apis
  • WORA for the desktop doesn't exist - Just about everyone writes Windows apps in Java (even the Linux crowd, who mostly write Windows 95-style apps in Java). I'm predominantly a Mac user, so it's easy to spot the Windowsisms everywhere.

Great post! In addition to your two C++ painpoints, I would add porting. Taking a large existing application that works fine with, say HP's compiler, and getting it to run on, say, Sun's compiler, was a nightmare. It was all standard C++, so it should be easy, right??? I'd also add core dumps. One stray pointer bug that happens intermittently and corrupts the stack could take days or weeks to track down. I was just ecstatic when I got my first Java NullPointerException and a nice, clean stack trace. One other painpoint for me was having to learn everything anew each time I joined a project. Because there was no real library (before STL), every project had it's own data structures (hash, list, etc), logging, algorithms (sorting), and as you mentioned database and GUI. I'm one of those that gripes about operator overloading, but I certainly agree that it was just uncomfortable, not a real pain. And even then, it was just programmer misuse and not an inherent language problem. Another thing I found uncomfortable (in C more than C++) was the error checking without exception handling. Having every darn function in the world return true or false to indicate whether it worked or not was just weird. Andy

@aberrant: Look into Foxtrot to improve your concurrency programming around the EDT in Swing. In some cases, it can be alot better than SwingWorker.

Well as far as the web goes, it's funny to watch people trying to turn the web into the desktop. Well, it's not the desktop and is never going to be the desktop...AJAX is a stupid Javascript trick, and like all tricks it's clever and entertaining and good enough for some things, but that's it. Rich client desktops that connect to web services are the once and future king of internet development. Where is my pain? No browser integration in Swing, no Flash or video support either. Ouch.
The attractiveness (read: alleged ease of development) of RIA is of course the runtime and container of your app is already distributed and you can interact with web services out of the box. That the container presents HTML so very well.
Web services in their turn are exciting because hosted software services is the only way anyone knows how to make (big) money anymore. It turns your app into an appliance and your company into a freaking cable provider. $50 bucks a month from 10 million people - woo hoo! At least, that's the story.
The data is out there. The UI is right here. Put them together and you'll have a winner. Just stop making every UI gesture amount to a hit to the server (JAXASS , er I mean AJAX notwithstanding) and leave that logic here, where it belongs. How hard is that to figure out?
Wish list
Flash support
OR
Video support to the core- it's just another object I write java against, like JTree.


HTML (Browser) support to the core...



Continual progression in the tools. Actually, most of what you complain about is a tools issue... the tools do not provide the highest level of abstraction they could.
None of the above is a language issue. DSLs will come and go with their Ds, but general purpose languages are here to stay and Java isn't going anywhere anytime soon.
oh now I see how formatting works...

Well as far as the web goes, it's funny to watch people trying to turn the web into the desktop. Well, it's not the desktop and is never going to be the desktop...AJAX is a stupid Javascript trick, and like all tricks it's clever and entertaining and good enough for some things, but that's it. Rich client desktops that connect to web services are the once and future king of internet development. Where is my pain? No browser integration in Swing, no Flash or video support either. Ouch. The attractiveness (read: alleged ease of development) of RIA is of course the runtime and container of your app is already distributed and you can interact with web services out of the box. That the container presents HTML so very well. Web services in their turn are exciting because hosted software services is the only way anyone knows how to make (big) money anymore. It turns your app into an appliance and your company into a freaking cable provider. $50 bucks a month from 10 million people - woo hoo! At least, that's the story. The data is out there. The UI is right here. Put them together and you'll have a winner. Just stop making every UI gesture amount to a hit to the server (JAXASS , er I mean AJAX notwithstanding) and leave that logic here, where it belongs. How hard is that to figure out? Wish list Flash support OR Video support to the core- it's just another object I write java against, like JTree. HTML (Browser) support to the core... Continual progression in the tools. Actually, most of what you complain about is a tools issue... the tools do not provide the highest level of abstraction they could. None of the above is a language issue. DSLs will come and go with their Ds, but general purpose languages are here to stay and Java isn't going anywhere anytime soon.

". They decry the fact that students can actually get useful work done with Java, just by taking a class here and a library there, instead of having to build everything from raw bits."

I don't understand why they just don't set a rule that only some core parts of the Java runtime can be used for such assignments. It seems more a problem of how to run an exam that of how Java is designed.

PS Yes, Slashdot attitude anti-Java has been debated (see here: http://weblogs.java.net/blog/editors/archives/2007/10/does_he_love_yo.html). The editor hates Java because in the early ages Sun prohibited him from using the Java name in a project he was developing. After reading that, I've pulled out SlashDot from the list of interesting sites, I'm interested in engineering, not in personal revenges.

The solution to the the pain of using Java is already here. It's the Groovy language. It's absolutely wonderful. Give it a try, you'll love it! It's so expressive and natural. Also look at Grails for web development. It's a brilliant piece of work. Both Groovy and Grails are built for the JVM so you don't have to abandon what you already know. It's the wave of the future imho. Scala looks great, but Groovy (JSR-241) has been out longer - the latest version is 1.5.1.

Why dont we stabilize JAVA and develop new language features as plug-ins that integrates well with JAVA, with this the user has a choice to add or remove new language features whilst mainting the stabiltiy of JAVA

Java is a good language for desktop apps. Leave it alone. I don't want it to turn into (C++)++.

Java sucks for web apps. Just like, umm, everything else. For all the hype about Rails/GWT/whatever-your-current-fad-might-be, there is no good framework yet for web development. The web is not the desktop - it's entirely different - but everything we have today for the web is just bows and bells on the same old desktop paradigm.

In my view, we need to fix existing Java features (most notably Generics) before moving onward to new features. I have nothing against new features but let's please first fix some of the complexity we've introduced with previous ones.

@bharathch: Is it anything but a pure coincidence that these emeritus professors at Adacore blame Java for all curricular woes? Is Slashdot inherently replete with anti-[Solaris/Java/Sun] trolls? I don't think a bunker mentality is going to help us. Let's analyze what ails Java and fix it.

Actually, the professors have the opposite issue with Java. For them, Java is too alive. They decry the fact that students can actually get useful work done with Java, just by taking a class here and a library there, instead of having to build everything from raw bits.

In fact, the entire article (http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html) is a case study in the behavior of dinosaurs in the wild.

(I've posted this on the editorial page, just for emphasis) Can we spare a few minutes(/hours) trying to count the number of times someone has proclaimed Java to be "dead","in its twilight days","on the decline" and so forth? A few points merit further consideration:
1)Is is a pure coincidence that two professors working for adacore came up with these statements against Java?
2)Any surprise that it came on slashdot (which is replete with anti-[Solaris/Java/Sun] trolls)?
3)Java wasn't built to solve world hunger or to teach device driver programming to sophomores.
4)Its is not a substitute for C. It cannot teach you pointer arithmetic. C should still be taught before Java.
5)There is no inherent problem with the design of the Java language and runtime as much as there is with the way they're taught.
6)A course on Object orientation should accompany a Java programming course.
7)Dispensing with teaching the language structure and the workings of the VM, and instead focusing on struts/jsp/servlet/hibernate at colleges in the name of "practical education" is not a very sensible teaching method, to say the least. (Breaking news: Java != JSP)
8)Breaking news again: Scala binds to the JVM. So, the Java platform atleast isn't a fossil yet.
9)A few "luminaries" can abandon Java and do whatever fetches them more money for now. Nothing stopping them. We live in a free world. Extrapolating that to the demise of Java is naive, to say the least.
In a few years/months/weeks/days, we will see more requiems sung for Java while (strangely?) Java continues to proliferate.

@guy_davis - WOW Fortrot! This is exactly what I was talking about thanks!

Java pains: If there is that much compromise with existing code bases then, Java should stop evolving. As a language 1. constructors, singletons, statics and initialization of resources: the whole process of lifting the minimal structure up is messy: use DI, conf files ... 2. glitches in inheritance, varargs : hiding ... I wonder why the "trainers" don't mind this ! 3. Desktop : anon inner classes et al with events, Swing, EDT, no good component model used, no attr properties, no standard resource management, no swing app framework finished, no good standard binding, no event bus, no good interactive UI design solutions, ... using strings as glue! : you end up with loads of spaguetti and boilerplate. Swing has too much surface and inherits some bad awt designs, RCP too big for most desktop apps. Although some of this stuff is being addressed, 90% of desktop code is a mess to look at and refactor. And we do not have html, js, sandboxes or some corp to put the blame on like others ... 4. Generics and arrays, autoboxing and nulls: problem solutions provided do not properly solve the problems. New features are no good fit, due to not being able to break previous language design decisions. 5. Design: packages, visibility, extending interfaces, checked exceptions: most paths of least resistance are bad, lots of antipatterns. As APIs: This is IMHO the most important, everybody wants new sexy language features, but what for? You still have to use the old APIs ... Perhaps for more roll-your-own fw :( 0. Some APIs solve the wrong problems, some have too much surface ... 1. Duplication of effort (Web fw, declarative UIs): everybody dissatisfied with existing tools, everybody starts an API-fw, most die, existing code bases full of dead APIs and roll-your-own frameworks. 2. Standard APIs full of rubbish and obsolete stuff due to compatibility. New features are not fully used to refactor the APIs. As JVM: 1. Little support for more dynamic features, more meta-programming ... 2. Strange, the languages that some push ...

The biggest problem with java? Compatibility. Specifically library compatibility. If Sun wasn't so attached to forwards compatibility library, public interfaces could evolve and code wouldn't fossilize in a morass of incorrect exception types, mismatched interfaces, boiler plate and abstraction leakage. Then when new language functionalities came around (closures) the language could adapt around them without compiler hacks.

Getting rid of property boilerplate would by my number 1 request.

Everyones code would be at least 20% shorter if we had real properties in java. I'm not talking about a revolution, just the elimination of setProperty and getProperty for trivial properties and easy event listeners. It would make Java much more readable and make swing more pleasant to work with. This could be done with @Property and @ListenableProperty and the boilerplate could be written for you at compile-time.

Please don't reply with "IDEs write the code for you". They don't read the code for you. The compiler should be writing the code for you if it is fully automatic enough for the IDE to write.

[i]Java sucks for web apps.[/i] The problem isn't Java, the problem is the whole notion of "web apps" as *applications* built using a content delivery / hypermedia platform (HTML/HTTP). HTML and HTTP are great for what they were designed for, linking and displaying documents (including images, etc). As a platform for delivering applications, they suck. Quit writing "web applications" and use JNLP, or even (gawd forbid) use the X11 protocol, whatever, if you need to display an application UI remotely. The right tool for the right job, and all that...

Just in case the connection wasn't obvious, EJB3.0 (or JUnit 4) wouldn't have been as useful without annotation support. So, carefully thought out, non-intrusive changes to the language are indeed good. I'm not against them.

Let's analyze what ails Java and fix it. One man's fix is another man's cognitive load. Its easy to get carried away with well-meaning language improvements without sparing much thought for the real-world implications of these changes (generics being a case in point). Sure we'd like to replace all the boilerplate with a new properties syntax or some kind of a shorthand morse code. But the result of that could be further alienation of the developer community and more "I love flex" ads. I'm not, by any means, against new features or improving the language. (For instance, replacing the EJB 2.0 boilerplate with JPA & EJB3.0 was much needed.) But we need to be careful in evaluating & introducing these features in a measured fashion. They decry the fact that students can actually get useful work done with Java, just by taking a class here and a library there, instead of having to build everything from raw bits. I'd urge everyone to listen to the first 2 minutes of Paul Hilfinger's lecture on sorting algorithms as part of UCBerkley's Fall 2007 Computer Science course (CS 61B) on iTunes. He clearly states that the study of those algorithms is necessary to ensure that the students have a very good understanding of the fundamentals. It is, however, not a substitute for real-world libraries (like Java Collections), he says. Obviously, while its important to know what tools to use while engineering real world applications, there is no substitute for a good foundation in Computer Science. That being the case, should a course recommend using Java to build a console based text editor, or C to build a web application, or a shell script to illustrate the fundamental sorting/searching techniques?

I think syntax matters. I have heard the following many times: 1) Python folks on how much they like clean syntax. 2) Ruby folks on how much they like natural syntax. 3) LISP folks on how much they like minimalist and customizable syntax. 4) C++ folks on how much they like turning operator overloading and custom type conversions into very concise and easy-on-the-eyes code. 5) Java folks on how much they like the look of the language ("it's beautiful") People will take exception with all of the above, and that's natural, everyone likes their own syntax. Java has lots of competition now, if it tries to look like any of the languages other than itself, it'll likely fail to attract the desired crowd and might risk losing its established base. JVM will go on of course, it is a powerful piece of technology, but IMO the more Java stewards attempt to tailor Java into the ivory-tower-academic-look with all the nifty symbols, the more it will appeal in inverse proportion to those who like the opposite. Once a language attains a certain feature-set, most of the modifications to it will revolve around syntax changes. Languages are interfaces to the Turing machine, having all the features such as closures is nice, but if one expression of closures looks familiar and another looks like a natural language which one has no propensity to learn, the individual making the choice might choose more familiar pastures.