Object Definitions Blog

I’ve spent way too much time in the last few months fixing and optimising table rendering performance for a high performance Java application I’m working on at the moment. The problems were particularly hard to find becuase the app supports customization of almost every aspect of JTable UI, with custom rendering for rows, columns and individual cells according to user preferences. Some users would get terrible performance on some days, which would seem to disappear the next.

Some of the issues were hardware and graphics driver related, and there have been various minor and major victories along the way (more about these later), but just yesterday I found a very significant defect in JTable.tableChanged().

The problem occurs when you call setRowHeight(int row, int height) on a JTable, to set a customised table row height. You only need to do this once, and that causes JTable to initialize its internal rowModel to maintain the custom row heights. From that point onwards, any update to the TableModel (even if it is just an update event for a single cell()) will be processed by JTable.tableChanged() in such a way that the entire table component is marked as dirty. So this forces the RepaintManager to repaint the entire table every time, even for single cell updates.

The code at which the long gnarled finger of suspicion points is at JTable line 4396 (in jdk 1.6.0_14) and line 3021 (in jdk 1.5.0_17), which is part of the processing for TableModel update events

Essentially, if there is no internal rowModel set up (i.e the user has not yet configured any custom row heights), then the call to repaint() in this snippit causes the entire JTable to be marked as dirty - so the RepaintManager repaints the entire table component rather than just the cells affected by an update.

The effect of this is dramatic. When I run my test class (included below):

***** Running test for table Standard JTable under 1.5.0_19
With all rows default height total time spent repainting table 24 millis
Setting custom row height for one row
With one custom row height total time spent repainting table 5427 millis
Thats 226 times slower than it should be to paint the table!

Here is a Fix for the issue

I’m amazed that this one hasn’t been identified and fixed already. I have produced a workaround by extending JTable to override the tableChanged() handling for update events. Fixing this has solved major problems for our users whose tables were configured to require custom row heights.

This works fine for for me in 1.5.*.
It will also work for jdk 1.6.* but it does not support the 1.6 table row sorting (you’d need to find a way to fire sortedTableChanged() events to the sortManager to do this when the updates are processed)

The following Test demonstrates the problem, and that FixedForRowHeightJTable solves it

This test pops up a JTable in a frame and then changes cell values to trigger repaints.
While doing this we replace the standard RepaintManager with a TimingRepaintManager, which keeps track of the total time spent by the Swing event thread painting the table
We first run the test for a standard JTable, then for my fixed version, with the following results:

***** Running test for table Standard JTable under 1.5.0_19
With all rows default height total time spent repainting table 24 millis
Setting custom row height for one row
With one custom row height total time spent repainting table 5427 millis

***** Running test for table FixedForRowHeight JTable under 1.5.0_19
With all rows default height total time spent repainting table 2 millis
Setting custom row height for one row
With one custom row height total time spent repainting table 25 millis

Needless to say, I’ve submitted a bug report for this one!
(although technically once might argue its an RFE, since the table still gets painted, anything which degrades performance this much is a bug in my book!)

There are occasions when it is useful to group commands together and execute several in combination. SwingCommand provides a CompositeCommandTask which allows you to group commands together in a single task which executes them sequentially.

TaskListeners on the CompositeCommandTask receive progress events as each child command is processed. The example below creates a String progress value to describe the current child command being processed.

Cancelling the composite task will cause the currently processing child command to be cancelled (if it supports cancellation), and will cause the composite task to abort processing for any remaining child command tasks. The reverse is also true - if the currently processing child command’s task is cancelled, this will cause the composite task to be cancelled and abort early.

If any of the child commands fail, the composite task will also fail with a CompositeCommandTaskException, which has the child task’s exception as the cause.

Here is a simple example of a composite task:

The composite task implements the getProgress() method to generate the String used in the progress event.

SwingCommand has support for cancellable commands. To support cancellation for a Task it is easiest if the Task extends InterruptibleTask. InterruptibleTask helps to implement the logic necessary to interrupt the background thread if cancel() is called.

When you invoke command.execute() on a SwingCommand instance, a reference to the Task which is created to handle the execution is returned from the execute() method. Getting the reference to the Task which is running can be useful - for Tasks which support the cancel operation, you may want to cancel the task by calling task.cancel()

To implement cancellation correctly, your Task must be able to respond to the interrupt request. There are two main cases to consider:

• Interrupting a task which is blocked on IO, or on some other blocking call
• Interrupting a task programatically by checking the isInterrupted() status periodically

Lets look at the first of these, interrupting a task which is blocking:

In the example above the Task extends InterruptibleTask. During the doInBackground() handler, the background thread is blocked for a time in the call to Thread.sleep(). When task.cancel() is called by any thread, the InterruptibleTask logic will trigger thread.interrupt() on the background thread. This will result in an InterruptedException being generated by the sleep() method. Because cancel() was called, InterruptibleTask will catch the InterruptedException and the Task will finish with cancelled set to true (task.isCancelled() == true).

Note, if cancel() had not been called, the exception would have been allowed to propagate through causing TaskListeners to receive an error message, and the command would finish in the ERROR state.


What if cancel is called before or after the background processing?

If the call to task.cancel() occurs before background processing starts, the doInBackground() handler will not be called, and cancellation will always succeed. If the call to cancel() occurs after doInBackground() has returned, the call to cancel will not succeed - in this case and the task will end with isCancelled() == false.

The doInEventThreadIfNotCancelled() method is only called if the task is not cancelled. (You could alternatively override doEvenIfCancelled() if you wanted to do some post-processing in the event thread regardless of cancellation).


Interrupting a background task using custom logic

Sometimes a blocked thread will not respond automatically to thread.interrupt(). This is the case during some JDBC queries, for example. In some cases you have to implement extra logic to interrupt the task, and you can do this by overriding the doInterrupt() method. This example demonstrates how you might handle interrupting a query on a JDBC statement:

In the example above, the basic processing is the same, but this time we have also overridden the doInterrupt() method, to close the JDBC statement if the background query is interrupted. This should cause the statement.executeQuery() method to throw an SQLException. Because cancel() has been called, this exception will be treated as the result of a cancellation, and the task will end with isCancelled() == true.

Interrupting a task by checking isInterrupted()

There’s just one more case to demonstrate. How to handle a non-blocking cancel. This is actually quite simple - you just need to periodically check the isInterrupted() method, and return early if necessary:

Here the doInBackground() handler enters a processing loop. On each iteration, it checks to see if isInterrupted() is true - this will be the case if cancel() has been called on the task. If so, it breaks the loop to end the processing early.

Note that a task is considered cancelled even if the doInBackground() does not return early, provided that when the doInBackground() method returns the background thread still has its interrupted flag set.

Whew - that’s a fair amout to absorb. But the thing to take away is that extending InterruptedTask makes handling cancel easy. There is very little boilerplate code in the examples above, and you shouldn’t need to work too hard to get this right.

Task States

It is possible to find the current state of a Task instance directly by calling task.getExecutionState();
There are six ExecutionStates: NOT_RUN, PENDING, STARTED, SUCCESS, CANCELLED and ERROR.

A task starts in state NOT_RUN. During the call to command.execute(), the state will change to PENDING. Once task processing begins (which may be some time later if the task is queued for processing or is blocked waiting for a thread from a thread pool) the state moves to STARTED. The final state will be either SUCCESS , ERROR or CANCELLED. In the case that a Task finishes in ERROR, you can obtain the Exception that caused the error by calling task.getExecutionException()

If a SwingCommand task handler method ( doInEventThread() or doInBackground() ) throws an Exception the task is considered to have failed. Any TaskListeners will receive an error() callback, and the task will end in the ExecutionState.ERROR state.

Ending a SwingCommand Early

If an exception is thrown during doInBackground(), the doInEventThread() handler will not be called. Instead, processing is aborted before doInEventThread() is called. This makes sense, because in most cases we will not want to update the ui if, for example, a task loading data failed.

However, sometimes you will need to perform error handling in the Swing Event Thread, or perform some processing whether or not an error occurs or the task is cancelled. For example you may need to stop a progress animation. These cases are best handled by a TaskListener, in the error() method, or the finished() method respectively.

The finished() callback always occurs, no matter if the task succeeds, fails or is cancelled. The TaskListener methods also allow you to perform handling only on success (the success() callback).

SwingCommand has good integration with the java.util.Concurrent, and this allows you to control which background thread will be used to run your BackgroundTask. You can specify the Executor which should be used by your SwingCommand.

This can be very useful. For example, there are occasions when it is important to ensure that only one background task of a certain type runs at a time. You could achieve this in the UI by disabling buttons or menu items while a command executes - but if your SwingCommand instance is shared and used in many areas of your application it might be nice to provide a firmer guarantee.

To achieve this, you could associate a single thread Executor with a SwingCommand. If the SwingCommand is executed again before the initial task has finished running, the second Task will then be queued to start processing once the first has completed. (Sometimes it is also a good idea to cancel the currently processing task at this point.)

Using a Thread Pool

Alternatively, let’s pretend there are many different commands in our app, and our users hammer buttons as if they were being paid per click. We don’t want to risk spamming the database server with requests (it’s probably on its last legs anyway!). A good solution might be to impose a limit on the number of threads which can concurrently run background tasks in our application. Once these threads are active, any new Tasks will be queued until there is a spare thread.

We could do this very easily by specifying a fixed size thread pool for all our SwingCommands. For example, the following code snippit creates a thread pool limited to three threads, and associates it with a command.

To make sure all our commands use the thread pool, we could subclass SwingCommand to supply the thread pool Executor as the default. We could then use ThreadPoolSwingCommand instead of the basic SwingCommand throughout out application.

Setting one-off Executors

Similar to TaskListeners, you can also specify an Executor to be used for a one-off invocation of a SwingCommand. You do this by passing an Executor into the execute() method.

Processing a SwingCommand synchronously on a background thread

Passing in an Executor to the execute() method in this way can change the way in which a SwingCommand is processed. Usually, a SwingCommand launched from a background thread is processed asynchronously, so as not to block the thread which calls execute(). However, in some cases you may want the current background thread to be used for the execution of the Task - in which case the call to command.execute() will not return until the Task has finished processing. In this case, you can pass in a simple Executor which runs the command on the current thread:

In the above example the normal threading guarantees for the Task are still obeyed - doInEventThread() will still be run in the Swing Event Thread. The background thread will be blocked while the EventThread does its work.

It should be clear from the above that the ability to set the Executor for a SwingCommand or a Task gives you a lot of control over the threads used to process your SwingCommands.

The progress animation triggered by the TaskListener in the previous example would at least inform the user that a SwingCommand is executing. However, sometimes it may be useful for a long running command to show publish interim results, or simply post more descriptive progress updates.

To help with this, as well as allowing you to set the generic type for parameters to your SwingCommand, the SwingCommand class also allows you to specify a generic type for a progress update. The following example demonstrates perhaps a simple case, in which an Integer progress event is fired:

You could do more sophisticated things by firing progress, and progress events make it easy to update the UI safely - remember that these messages are received on the Swing Event thread even if fired from doInBackground().

For example, you could use this mechanism to gradually populate messages into an ‘inbox’ while reading mail messages from a remote server. Or you could send an Integer progress update representing a percentage value, to update a progress bar with the current percentage of work completed by a background thread.

A common requirement in User Interfaces is to show an animation while a background task runs. How might this be accomplished using SwingCommand?

The following example shows how you can add a TaskListener to a command. The TaskListener will receive events as the command executes, and start and stop an animation.

TaskListeners always receive their events on the Swing Event thread, even if the Task is a BackgroundTask.

Every time the command is executed, the SwingCommand creates a new Task instance, and the TaskListener will receive events while the Task runs.

It’s also possible to add a TaskListener to receive events for a single SwingCommand invocation, by passing it as a parameter to the execute() method:

The ability to add TaskListeners to SwingCommands is a key feature of SwingCommand, and it can be very convenient. For example, you could create several different commands and add a shared listener which tracks the background tasks and updates progress components on your UI. This listener will receive events on the Swing Event thread whenever one of the commands is executed, no matter which thread or which class actually executes it.

Separation of concerns

TaskListeners are a very useful mechanism. They allow you to separate the logic for handling progress animations, and error handling logic, from the main Task processing logic. You could, for example, provide a TaskListener which performs consistent error handling for all of the commands in your application. This is a good separation of concerns. Mixing that logic in with the main command processing logic tends to clutter the code up and make classes less easy to reuse - and there are certainly cases where you might want different error handling depending on the situation in which the SwingCommand is executed (e.g. if it’s executed in response to a button click in a Dialog, you may want to show an error message in the Dialog, rather than the main UI frame). To achive this, you can add some listeners to the SwingCommand, which will get notified whenever it is executed, and others context specific listeners can be passed as parameters to SwingCommand.execute().

The TaskListener interface

There are actually six listener methods in the TaskListener interface. Some of these are always invoked, others are only invoked if a Task enters a specific state (ERROR or SUCCESS) for example. To avoid having to implement all the methods, you can extend TaskListenerAdapter.

The full definition of the TaskListener interface is below:

This is the first of several blog posts in which I’ll demonstrate how to use the SwingCommand library to handle background tasks in Swing apps.

SwingCommand version 2 has recently been released, and it contains a lot of improvements.

It’s high time to add more documentation!

First let’s recap a bit.

SwingCommand targets the same problem area as SwingWorker - namely, how to handle background tasks and update the UI safely in Swing. Recall that you should generally only access Swing components and their models on the Swing Event Thread, due to Swing’s threading model. See the Swing tutorial if you are unfamiliar with this.

The main difference between SwingCommand and SwingWorker is that each SwingCommand instance can be executed multiple times. Each time you execute a SwingCommand, a Task instance is generated, which performs the processing and wraps the state and any parameters used for that execution. This means that SwingCommand instances can be created once and shared throughout your application. (There’s nothing to stop you creating a SwingCommand for one-off use, if this makes more sense in some situations).

This is how to create a simple SwingCommand

The task created by the SwingCommand above does not do any processing in a background thread - the doInEventThread() handler method will always be called in the SwingEvent thread, even if another Thread calls the execute() method. To create a task which does run in a background thread, we would need to extend BackgroundTask rather than extending Task directly.

Why would you want to create a SwingCommand which doesn’t run a background task?

Well, one of the main drivers for this, and for the Command pattern in general one might say, is reuse. A SwingCommand encapsulates a chunk of ui logic which can be shared throughout your app. Whenever you find yourself tempted to duplicate ui code, that’s a good time to consider creating a SwingCommand.

It’s also nice that both ‘Background Tasks’ and ‘Event Thread Only tasks’ extend the same Task abstraction, so that in many places in your client code, you need not descriminate between the two types.

If your command does need to perform processing on a background thread, it should create a task which extends BackgroundTask. The following example shows how you might write a command which queries the database to retreive some email messages for a user:

Creating a command which performs some work on a background thread:

The SwingCommand above runs a database query in a background thread, and then updates a text area in the Swing Event thread. The command could be created and executed either from the Swing Event thread or from a background thread, and SwingCommand will ensure that the call to doInBackground() occurs in a background thread, and doInEventThread() occurs in the Event thread. In fact, the command could be created in one thread, and executed from another and this guarantee still applies.

One thing to note - in both the above examples, the Task type created by the SwingCommand is an inner class. This is purely for convenience, since it is often easiest to write SwingCommands this way. If you prefer not to use an inner class for this, it’s quite possible for a Task to be implemented as a top level class.

Passing parameters to Commands

Commands often take their parameters from Swing components - for example a value from a JSpinner or a JTextField. In this case, the simplest way to manage things is often to construct the SwingCommand with a reference to the inputs - then when createTask() is called you can read the values from the components and use them in the Task. You can either construct the Task with the parameter values, or if Task is an inner class pass them in as final reference, as below:

Whenever the above ClearMessagesCommand is executed, it will read the current value from the supplied text field and use it to clear the messages for the named user.

The above pattern is nice because any of your other classes which want to execute the command don’t need to know about the text field. They can just call command.execute(). There may however be instances where you want to pass a parameter into the command when you call command.execute(). This is also possible. When you create a SwingCommand, you can define a generic type for a parameter. You can pass in instance of that parameter into execute(), and then access it from within the Task which is created.

The command below requires a String parameter. This is the first of the two generic types specified for the SwingCommand. The second String specified in SwingCommand actually defines what type of progress object the command can publish - but we’ll talk more about that in another example.

So the command above now expects to be passed a String username via the command.execute() method. Ideally it would be good to check that this has been set in doInBackground(), and if not either supply a default value or throw an Exception to indicate the command execution failed.

You probably have a lot more questions about the example above. For example, ‘How would you show progress to the user?’, ‘how does it handle any Exceptions generated during doInBackground?’, or ‘what controls which background thread runs the Task?’. I’ll address these issues in subsequent posts.

I recently saw an answer to a generics question on stack overflow where an incorrect (or at least misleading) answer has been voted up to the top. Sometimes generics are just a bit unintuitive.

Here is the example in a nutshell -

In fact, the code above would not compile. That’s the wrong way to interpret the lower bound wildcard. The variable l actually refers to a List which may be restricted to contain any valid superclass of Shape - and we don’t know exactly what type of List it is from the lower bound reference. It may actually be a List of Drawable (if Shape extends Drawable), in which case adding an Object to it would not be safe - since an Object is not necessarily Drawable. It may also be a List of Shape instances (since Shape is the lower bound), in which case adding an Object to it would also be invalid. That’s why the example above does not compile.

There is an important principle set out in Java Generics and Collections, called the ‘Get and Put Principle’ which helps to explain when to use lower and upper bound wildcards

Use an extends wildcard when you only get values out of a structure, use super wildcard when you only put values into a structure, and don’t use a wildcard when you both get and put.

Proper use of this rule can make your classes more flexible. Partly to make sure I’ve got this fully straightened out in my own head, I’ve put together an example which illustrates the get and put principle, and helps to explain upper and lower bound wildcards:

Isn’t it nice when once in a blue moon somebody comes up with an innovation which makes your life just that little bit simpler - one of those little things which you soon take for granted, but you’d miss immediately if it was not longer there. In this case, it’s the Maven 2 plugin which automatically updates your source files with the appropriate license details

Maven License Plugin

Until now this was an annoyingly manual task which was just not quite annoying or time consuming enough to merit spending time automating. It was one of those borderline annoyances which you plan to do something about, every time it bites you. However, in this case it is always the last action before cutting a release, when you’ve had a long hard day, the caffeine has worn off (and it’s a bit late for another dose, you’d never get to sleep) - you’re running on an empty tank and you’d really like to get out of the door. Over time these small tasks stack up and sap your energy.

That’s why this plugin is such a life saver. It does just what it says on the tin, took about 5 minutes to set up and get going - saving time the very first time I used it, even taking into account the minimal setup and configuration.

Every time I find a new plugin like this I’m reminded of some of the great things about maven - particularly the convention over configuration, which facilitates such easy sharing and reuse, and allows most features to ‘just work’. For sure, there is a learning curve associated with maven - but once you’re up to speed the benefit really shows.

This is a fuller version of the code snippit I submitted to the interesting thread on java synchronization issues on stack overflow

In general it can be tempting to assume too much thread safety when using synchronized collection classes.
It can be easy to think they somehow grant you more protection than they actually do, and forget to hold the lock between calls.

If have seen this mistake a few times:

In the second line above, the toArray and size() methods are both thread safe in their own right, but the size() is evaluated separately from the toArray(), and the lock on the List is not held between these two calls. If you run this code with another thread concurrently removing items from the list, sooner or later you will end up with a new String[] returned which is larger than required to hold all the elements in the list, and has null values in the tail, which will quite possibly result in a NullPointerException eventually.

It is easy to think that because the two method calls to the List occur in a single line of code this is somehow an atomic operation, but it is not. The best way to fix this is to hold the lock explicitly :

For quite a while now I’ve been a subscriber to O’Reilly Safari bookself. It contains a lot of useful books on a wide range of technical and programming topics.

Although there is a good selection of material on the site, I haven’t really made the best use of it until now, since it has in general been less accessible than other web resources (it has just been easier to google for material than navigate to the O’Reilly site, log in, find the right page, search for books etc.). This devalued the whole Safari experience.

However, there is now a search bar plugin for safari (available from the tools page) which allows you to treat Safari as a search engine, and makes its contents available from the search box integrated with your browser toolbar. This innovation is the killer feature for Safari, in my opinion. Suddenly it makes the Safari content as accessible as the rest of the web. Suddenly, I don’t seem to have enough slots in my Safari bookshelf account any more, and the subscription fee seems quite reasonable.

I finally completed open sourcing SwingCommand - an open source library which provides support for the command pattern in Swing. In addition to synchronous commands, it provides support for asynchronous commands, which hides away the gory threading details in a similar way to the SwingWorker class - but in SwingCommand the asynchronous commands are integrated into the overall framework, and there are a few extra features, such as composite command support and command execution observers, which I hope make it more flexible.

Reusable Commands

One other key difference from SwingWorker is that in SwingCommand each command instance is reusable (a command can be executed more than once). Each time you call myCommand.execute() a ‘CommandExecution’ instance, which encapsulates the state for that execution. In the SwingWorker provided as part of jdk 1.6, each SwingWorker instance is designed to be executed only once. In SwingCommand there is nothing to stop you creating a new Command instance each time if you prefer, but you also have the flexibility to create a shared Command instance up front, pass references to it around your application and execute it many times if necessary.

Why a new Command library?

There is nothing fundamentally new about using the command pattern in Swing apps, but arguably there is a need for a reusable library to address this problem in a focused manner, and provide a richer set of features than SwingWorker, without attempting to solve every other ui programming issue along the way. SwingCommand has certainly been a useful library in my projects already. It does hide away a lot of the more complex threading issues, typically produces ‘clean code’, and make it easy to build a Swing application around chunks of reusable logic wrapped as Command classes. Integration with java.util.concurrent framework makes it really easy to handle threading issues which would otherwise be complex (e.g to prevent two instances of the same asynchronous command from running simulatenously would be a one line change, by using Executors.newSingleThreadExecutor()).

A milestone

This is the first of Object Definitions’ libraries which I have open sourced. It is fair to say it has been more work than I anticipated to get it to this stage - so it is probably time to crack open a bottle of something fizzy. Once I have recovered from the hangover I’ll post more about it here. In the meantime there is a lot more information on the website and you can download swingcommand library here

I just switched to using a Linksys NSLU2 NAS server for my home network.
It’s a great little thing - you just connect USB drives to it and set up network shares using the nifty web administration utitlity.

None of this is new - the NSLU2 (or ’slug’, as they are known) has been around for years now, and there is a cottage industry of linux kernal hackers grown around it, to adapt it to do such things as streaming music etc.

What is new, however, is that it won’t work from Vista. Works like a breeze from XP.

The linksys requires LM authentication which was supported by default by XP, but apparently it is disabled by default in vista, which only supports NTLM out of the box. I suspect this is not Linksys’ fault. The upshot of this is that from your spanking new Vista laptop you won’t be able to log in to your home network devices any more. You’ll probably forget they’re even there. The only person who will be able to log into them will be the guy parked up in a van outside who’s hacking into your wireless network using Windows XP. How’s that for security?

The forums are riddled with messages complaining about this, for the linksys and other similar NAS devices.
Most of them refer to now defunct Vista system administration tools
Searching the Vista help gets you nowhere.

Eventually I found a post which contained a registry setting to edit, to enable LM authentication
A registry setting to edit? Whooo, lucky me.
Welcome to the wonderful world of Windows usability.
If there is a utility which allows you to set this, I’d love to know, Windows admin dialogs are a joy.
I suspect I might be still looking at Christmas given how intuitive the admin is in Vista.

Anyhow, the magic LmCompatibilityLevel registry setting can be changed to let you log in to your network devices:

Note, changing this won’t make your network more secure. However, for your home network it should be OK, provided you’ve secured your wireless network. Any self respecting burgler walking into your appartment probably won’t be spending too much time trying to hack your network passwords. They’ll simply pick up your NAS drive and stick it under their shirt while pretending to read the gas meter, and make off with any win XP laptops (although they may leave your vista machine where it is)

You can edit the registry using the regedit utility
Have fun!

I’ve been looking for a screen splitting program for quite a while but somehow this one passed my by.

There isn’t much point in the 4 million pixels in the HP LP3065 unless you can easily arrange windows on the screen. Typically when working I need to run 15 to 20 apps, and view several simultaneously - and its a real waste of pixels if you can only maximise one window.

For a while, I was forced to go back to two screen setup, with smaller monitors, just so that I could easily maximise two apps.
But now that 30 inch monster is back on my desk, ooooh yea, with WinSplit revolution will never be separated again.

It’s a great little app which gives you hotkeys you can use to reposition windows in the screen either left or right, top or botton, in the corners or maximised. You can also use it to move windows between screens. That’s just the beginning - there are plenty of other great features too. So much so that I even find it useful on the 1280×1024 monitors at work. And, did I mention, it’s free? Forget windows power toys - this has instantly become my number one favorite windows utility.

Of course the real irony is that a free utility like this can provide such a huge improvement to the ‘windows’ os, which, despite costing hundreds of dollars, doesn’t even seem to offer the basic minimum ‘window management’ features required to use the software at a professional level. The windowing in vista, if you discount the ridiculous flip 3d switching gimmick, doesn’t seem to have changed an awful lot since win 3.1, when we all used to make do with 640×480 resolutions. Both linux and the Mac offer virtual desktops these days. There was a power toy which simulated this for XP, but it seems to have diasppeared from the Vista world. If anyone finds an equivalent, please let me know!

I’ve seen far too many bugs lately involving lazy initialization.

In theory lazy initialization might seem a good idea. Why do extra work up front which might not be needed?

The problem is that it is simply too easy to introduce bugs when state is not completely loaded after construction. For example, a project I recently worked on made extensive use of init() methods to lazily load state on demand. The constructor would not do the initialization. Instead, each getter method would check whether initialization was complete, and if not kick off an init() process before returning data.

The reasons for this were fairly convincing. The loading of the state required a call to a database, which was slow. But the problem was that this lazy initialization pattern soon spread throughout the codebase like a rash. Soon it was rare to find a class which was guaranteed to be ready for use after construction.

Still other classes used lazy loading as a speculative performance optimization. Table models received events which invalidated their internal state. Instead of recalculating immediately, they propagated events to their listeners, delaying their own recalculation. The models would recalculate only when a client class called a method to ask for data, and forced a the model to check its state and recalculate. Again, it sounded good - why take on the overhead of immediate recalculation if your class has no active listeners?

The original coders left. The code base gradually expanded to more than a million lines of code. New programmers arrived. Predictable problems emerged.

In many cases, the new programmers would simply fail to realise that an object was not ready to use until its init method had been called. Init methods had become a part of some key abstractions - although in the vast majority of cases subclasses did not actually require any special initialization. So most objects ended up with an init method, just to cater for the few places where it was really necessary. Confusion reigned as to when and where initialization should take place.

Interfaces changed and classes needed to be modified. It was all too easy to forget to check the initialization status when adding methods to existing classes. Strange errors occurred in the table models. The data had changed some time before, but since the recalculations were delayed it was hard to work out from the logs what had actually triggered the problem. Sometimes the original coders had made mistakes and forgotten to check the initialization state for some methods. In other subclasses had overridden methods and forgotten to include the check. Problems could emerge quite unexpectedly, such as when the ordering of client class method calls changed. This often caused strange data corruption or null pointer exceptions at runtime, which brought down components.

The basic OO tenet that an object should be ready for use after construction really does make a lot of sense - try very hard to avoid lazy initialization wherever possible. It may seem clever, but it probably isn’t. If it seems that lazy initialization is the only way, reconsider every alternative design. Simplicity is key, and lazy initialization or lazy recalculation is rarely, if ever, simple. You’ll likely save yourself some headaches in the short term, and in the long term you’ll save even more for those who inherit the code once you have moved on.

For a recent project I needed some code to calculate a colour gradient for different points on a scatter chart. The class below performs a simple interpolation between two colours, if you feed it a value between 0 and 1.