In the comments on the entry on spring effects under third-party LAFs, Chris has asked if it would be possible to make this functionality available under the platform's system look and feel. My first response mentioned one possible way to do this - download the sources for JDK, create a custom Ant build script to inject this functionality into core LAFs (such as Windows or Ocean), take the resulting jar and use the boot classpath switch to have JVM load this jar before the classes in rt.jar.

Now, this approach has a few disadvantages:

  • You inherit all the bugs in the specific package that you're taking. Any code changes to the core implementation will need to be incorporated into the widgetized binaries.
  • The size of the resulting jar file will be unnecessarily big, since it will contain the same functionality as the core classes + the injected behaviour.
  • Application startup scripts will have to be modified to point to the new jar (as boot classpath option).

One big advantage of this approach is that the existing application code (call to UIManager.setLookAndFeel) doesn't need to be changed, since the class name of the main LAF class remains the same.

Well, it so happens that the above approach is not the only way to tackle the request (and no, it's not an April Fools joke). The new laf-widget-windowssubproject provides another way to inject widgets, transition layout and image ghosting effects into the core look and feels.

First, here are two screenshots of a sample application under a widgetized Windows look and feel, one under Windows Vista and another under Windows XP. Note the menu search widget, tab overview widget, password strength checker widget and lock widget on uneditable text components: 

Here are two Flash movies showing the widgets and the transition layout in action (under Windows Vista and Windows XP):


Here are two Flash movies showing the ghost effects (rollover icon ghosting and button press ghosting) under Windows Vista and Windows XP:


Here is the code for the only class in this project:


public class WindowsLookAndFeel extends {

All the rest is taken care of by the custom Ant tasks. This way, all the disadvantages of the first approach are addressed - the code is not tied to a particular implementation of the core LAF, the binaries size is kept to the minimum, and you don't need to change the boot classpath. On the other hand, you now have to use the as the parameter to pass toUIManager.setLookAndFeel.

Feel free to download the binaries and leave comments.