A great deal of rich-client user interfaces rely on some form of animation and special effects: Fading components in and out, or smoothly moving parts of the user interface in response to user interaction, in turn, are examples of effects that rely on some notion of time.

Working with time-based events in Java has so far centered around two Timer classes in the JDK. While those classes provide the basics, Sun's Chet Haase noted that they don't define a high enough abstraction level API for the requirements of rich UIs. To fill that need, Haase set out to define the Timing Framework API, and released its 1.0 version today. In describing the need for the Timing Framework, Haase noted that:

Any time you introduce dynamic effects, animations, or time-based events to a Java application, you find yourself re-implementing the same functionality you have written for every application that required timing or animation. The built-in APIs are powerful, but they require that you write a fair amount of boilerplate code.

The timing utilities in Java, java.util.Timer and javax.swing.Timer ... can help you schedule time-based events. These classes let you create one-time and repeating events that will call into your application at scheduled intervals so that you can cause things to happen at those times.

This is a standard way to handle time-based events, such as animations; you are essentially telling the system "wake me up every n milliseconds." When you are woken up, you perform the appropriate action (change the appearance of an animating cursor, move an object on the screen, poll the network, send mail to your boss telling her how productive you are, whatever).

These are great utilities as far as they go, but I find that they don't go far enough. There is always other time-based functionality that I end up layering on top in order to deal with real application needs. For example, I usually want to run a timing event (such as the fading in of a component) for a set amount of time, but the Timer utilities assume one-time or indefinite operation and must be manually stopped when you are finished with them...

I thought it would be useful to codify some of the generic functionality that I tend to need into a higher-level utility that makes using timers a bit easier (at least for me)

The API is documented in Haase's recent book, Filthy Rich Clients.

What do you think of the Timing Framework API?