Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

swinging twinsWhen I first heard about JavaServer Faces, way back at the 2002 Java One conference, it was sold as “Swing for the Web”. That caught my attention. I was sick of “assembly programming for the Web” with HTML, JavaScript, HTTP, cookies, servlets, and that special form of torture—JSP custom actions. Ever since, I have pinned my hopes on JSF because it has one thing going for it: a component model. When I need, say, a progress bar, I want to leave it to someone more skilled than me to make such a thing out of images, JavaScript, or whatever. I just want to hook it up to some property that has a progress value and move on to the next task. After all, when I use a JProgressBar in Swing, I don't worry about the pixels and animations either.

In that regard, the first release of JSF was a cruel disappointment. The standard JSF components are very primitive. The most sophisticated one is the data table, and it pales in comparison with a Swing JTable. No progress bars, trees, menus, popups, or any of the other building blocks that you want for a snazzy application. I don't want “FORTRAN for the Web”.

In the last couple of weeks, I had to hack together a simple system to support classroom discussions. The instructor puts up a question, students give anonymous answers, and then the class looks at the collective wisdom and has a (learning insight|good chuckle). Many instructors use “clickers” for this purpose—special hardware devices with voting buttons. But I wanted students to send text and images, not just multiple-choice answers. (Also, they all already have a laptop, but they'd have to buy the clicker.)

elephantAt first, I thought, oh no, don't make me eat the elephant again, and I longingly looked at Rails, Grails, or Lift for my salvation. But then I googled for "Rails progress bar", and the results were depressing. I noted that NetBeans 6 has a perfectly good progress bar in the Woodstockcomponent set, so I decided to go with JSF once again. This time, Swing for the Web seemed within reach. Here is what worked and what didn't.

  1. up The Woodstock components look pretty nice—much nicer than anything that I could put together with my limited CSS skills. For example, the alert component has some shading, some graphics, all that stuff that I am too busy to work on. Exactly what you want from a component set.
  2. up The progress bar worked great. I didn't have to know anything about AJAX. That's good because I really don't want to know any more about AJAX than about ASN.1. For an application programmer, this should just be plumbing.
  3. down The documentationfor the Woodstock components is totally wretched.
  4. left The NetBeans form designer is adequate for dragging together a basic UI, but it insists on the “Creator” model where each JSF page has a backing bean with bindings for each component. That may make sense for ASP.NET programmers, but I hated it. Apparently, this will go away in Netbeans 6.1. I used the form designer for the initial layout, then converted everything to plain JSF. I also had other issues that hopefully will get addressed in a future version of the UI builder.
  5. down Achieving a common page layout, with a title bar on top and a menu on the left, is still way too hard. I want the framework and tools to guide me, not fuss with page fragments.
  6. up I used the XML JSP syntax and XHTML for the pages, and NetBeans caught all my silly formatting errors—a big help. (Why don't I follow that good advice in Core JSF? I tried, but my co-author and the reviewers all felt nostalgically attached to ye olde syntaxe.)
  7. up NetBeans is pretty good about keeping the various configuration files in sync, and I didn't have to fuss much withfaces-config.xml.
  8. left If I had used Seam, I could have ignoredfaces-config.xml altogether, but I ran into some GlassFish problems. Once WebBeans is integrated into NetBeans/GlassFish, I will definitely go that route.
  9. up JPA was a winner. Having the ORM and caching for free is nice, and JPQL is far less tedious than SQL. I spent essentially no brain cycles on persistence. Mostly, that was because my app is so simple that I never felt the need to export any entities outside the managed environment. Again, Seam/WebBeans would make this even nicer.
  10. down I still got the Stack Trace From Hell far more times than I wanted to. NetBeans did a fairly creditable effort in trying to scrape what little useful file name/line number data it could find. This still needs lots more work. For example, errors in session beans are silently swallowed.
  11. up The NetBeans debugger saved my bacon many times. It is very savvy about tracing from a JSF bean to a session bean, bypassing the intermediate layers.
  12. down I tried my best to use hot deployment, and even hot-switched code whenever possible. But every time that I edited a JSF page or even a CSS file, I had to redeploy, redeploy, redeploy, and each time, I stared at the console for what seemed like an eternity. I hated that. My Rails friends tell me that they can keep tinkering with their code without ever redeploying.

Overall, I felt that I still had to focus far too much on the care and feeding of the app server. GlassFish programmers—remember that the app server is not just a tool to run perfectly working applications, it is also a part of the development environment!!! We need good error messages and red-hot deployment to be productive.

Swing for the Web is getting closer. Woodstock, RichFaces, Trinidad, all show promise. But do we really want all of them? After all, there is just one Swing. And if we must have them all, they should all play nice in a web GUI builder. JSR 276 should get us there—that started in June 2005. How time flies!

Apart from the UI components, we need more architectural guidance for mediating between the UI and persistence layer. I think JPA with Seam/WebBeans is our best bet, and NetBeans should support it ASAP.

All these issues are solvable, and I am hopeful they will be solved. I did enjoy having the Java API for all those other things I needed to do (such as crypto, zip file management, image manipulation, and so on). In the end, I was able to hack together a somewhat nontrivial application using NetBeans, GlassFish, JSF, and JPA, in a couple of weeks, while at the same time contending with sick infant twins and a broken clothes dryer. Not bad...but it could have been one week without the Stack Trace From Hell and redeploy, redeploy, redeploy. 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 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? 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 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 mecomponents 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 orthis, 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 continuationsmake 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?