~pperalta

Today JBoss announced that it has acquired transaction management technology from Arjuna Technologies and HP. They plan on releasing it as open source and integrating it into the application server by the end of Q1 2006.

This is an interesting development because one of the areas where JBoss has always lagged behind the commercial offerings has been distributed transaction management. In particular, the JBoss transaction manager does not perform logging. Distributed XA transactions can still be done, but the lack of logging could lead to data loss if the application server or one of the transactional resources goes down (which kind of defeats the purpose of XA). If this integration works well it could open up opportunities for JBoss in sectors where a commercial app server was the only option.

When I was a senior in college, I wrote a Java front end for controlling X10 devices. In those days, libraries for serial port access did not exist for Java, so I used JNI to call a serial library written in C. When presenting this project to faculty and classmates, one of my presentation points was that checked exceptions were a good thing. This forced the programmer to handle operations that could go wrong instead of ignoring them. In fact, during my demo, a catch block that I had coded to handle IO problems displayed an error dialog. The checked exception forced me to handle that error even though I had never seen it before! This occurred because the demo was being held in the CS lab with lots of other machines on the power grid, whereas all of my previous testing was done at home, where there was much less interference on the line.

Lately I have seen a few blog entries discussing the checked vs. unchecked debate. The first place I can remember reading about this debate was in Expert One-on-One J2EE Design and Development a few years ago. In this book, Rod Johnson advocates the use of unchecked exceptions as the norm and checked exceptions in edge cases instead of the other way around.

Up until that point, I was still a checked exception fan, although I had some misgivings. I had two major pain points with checked exceptions:

• If a method throws a checked exception, any interface methods that it implements must also declare the exception. Often, this exception has nothing to do with the interface.
• What do you do with a checked exception if it can’t be handled where it is being thrown? If you declare that the method throws that exception, that change may have a ripple effect throughout the code base. Before JDK 1.4, wrapping an exception with another one meant loosing the stack trace unless you implemented your own exception type.

After dealing with the pain of many checked exceptions that I could do nothing about (and the boiler plate try/catch blocks that go with them), I am firmly in the unchecked-exceptions-as-normal camp. This is especially true in server side programming, where a SQLException that is nested deep in a DAO usually can’t be reasonably handled and thus has to make its way to the UI to let the user know that something went wrong. I think the reason why checked exceptions worked so well in my college project is that the UI was a thin layer over the JNI library. When working at the UI level (especially in a desktop application), it is helpful to know what can go wrong because it is easy to display an error message of some sort to handle the exception. However, most of the time applications are making deep calls into APIs which call other APIs. For non trivial applications, unchecked exceptions are the way to go.

For further reading on this topic, see this article by Bruce Eckel.

I just tried out Ruby on Rails for the first time after reading the article “Railing on AJAX” in the November 2005 edition of Software Development. I first saw RoR in action at No Fluff Just Stuff demoed by Dave Thomas. This is a framework that strictly adheres to the DRY (Don’t Repeat Yourself) principle, which means that changes in configuration are only required in one area instead of having rippling effects throughout the application. It also relies heavily on convention instead of configuration, so once you’re familiar with the setup it is quick and easy to add functionality. Scripts are provided for generating web applications, controllers within those applications, and more. It also comes with an ORM tool known as “Active Record” which is supposed to be very nice for simple CRUD operations.

This article also mentions the AJAX support provided by RoR, and it gives a simple example of how to use it. In the example, no JavaScript coding is required…the application comes with JavaScript libraries called from Ruby for performing the AJAX calls.

Ruby, RoR and AJAX have received quite a bit of press coverage lately. It will be interesting to see how they affect the industry in the coming months and years.

A few days ago this strange posting was made on the front page of TSS. It seems to me that this would be a more appropriate question on a “JDBC for Newbies” forum somewhere, not on the front page of a major news site for server side Java. Even stranger (or perhaps just scary) is that this code supposedly came from a Sun tutorial. As Keith Donald points out, using Spring’s JDBC support would go a long way toward cleaning up that code. However, one of the biggest problems that I see with the sample is that the prepared statements, result sets and connection are not closed in a finally block. In my experience with Oracle, if everything isn’t closed out explicitly, you could end up running out of cursors. Just closing the connection will return it to the pool; that won’t be enough to clean up the connection’s resources. However, using Spring JDBC would make that point moot…Spring will close everything properly for you. Notice that Keith’s example isn’t cluttered with try/catch/finally blocks!

Meet the Life Hackers, an article from the New York Times has been mentioned by Slashdot and Joel Spolsky in the past few days. It is a long article, and it covers many aspects of office and knowledge work, in particular how we interact with modern office technology. However, there is one section of the article that I found particularly interesting:

When Czerwinski walked around the Microsoft campus, she noticed that many people had attached two or three monitors to their computers. They placed their applications on different screens – the e-mail far off on the right side, a Web browser on the left and their main work project right in the middle – so that each application was “glanceable.” When the ding on their e-mail program went off, they could quickly peek over at their in-boxes to see what had arrived.

The workers swore that this arrangement made them feel calmer. But did more screen area actually help with cognition? To find out, Czerwinski’s team conducted another experiment. The researchers took 15 volunteers, sat each one in front of a regular-size 15-inch monitor and had them complete a variety of tasks designed to challenge their powers of concentration – like a Web search, some cutting and pasting and memorizing a seven-digit phone number. Then the volunteers repeated these same tasks, this time using a computer with a massive 42-inch screen, as big as a plasma TV.

The results? On the bigger screen, people completed the tasks at least 10 percent more quickly – and some as much as 44 percent more quickly. They were also more likely to remember the seven-digit number, which showed that the multitasking was clearly less taxing on their brains. Some of the volunteers were so enthralled with the huge screen that they begged to take it home. In two decades of research, Czerwinski had never seen a single tweak to a computer system so significantly improve a user’s productivity. The clearer your screen, she found, the calmer your mind.

Having lots of screen real estate has always been very important to me. In fact, when I was in college (and poor, but I’m being redundant here) I spent $600 on a 17″ CRT at a time when the average PC had a 13″ or 14″ monitor. Having a larger monitor and being able to fit more text on a single screen makes me feel much more productive, especially when coding. At work I was using a 19″ LCD for a while (since LCDs are so much easier on my eyes, but I digress) and the 1280×1024 resolution felt very constraining. Getting a 20″ monitor that does 1600×1200 felt quite liberating. Even though it is only 1″ bigger, the difference in resolution is huge.

Having multiple monitors sounds intriguing, but I’ve tried it before and I find it more distracting than productive. I prefer to just have one large monitor…that 42″ model sure sounds nice!

As Joel says, it is nice to have scientific evidence to back anecdotal feelings!