Changing look and feel for all current frames I am using JGoodies Looks to change the look and feel of the application I'm currently working on.

I've just created a JMenu with some different themes options for the user to choose.

The thing is, I want to make sure the changes affect the program instantly, on all current windows, so I did this:

@Override
public void doActionPerformed(ActionEvent event) {
    PlasticLookAndFeel lookAndFeel = new PlasticXPLookAndFeel();
    lookAndFeel.setPlasticTheme(new SkyBlue());
    try {
        UIManager.setLookAndFeel(lookAndFeel);
        for(Frame f: Frame.getFrames()) {
            SwingUtilities.updateComponentTreeUI(f);
        }
    } catch (UnsupportedLookAndFeelException e) {
        e.printStackTrace();
    }
}


It works perfectly, like magic. But I don't know if it is a good practice or not, or if there is a better or easier (if possible) way.

I didn't even know that Frame had that method. I've just tried (thanks to IntelliJ magic code completion) and it worked so easy on the first try. So maybe that's why I'm concerned about it.

Also, what is the difference between the code above and this one (as they appear to work the exact same way):

for(Window window : JFrame.getWindows()) {
    SwingUtilities.updateComponentTreeUI(window);
}


I mean, when and why should I be using Frame over JFrame, Frame over Window, or vice versa?
Java GUIs: Swing &amp; AWT

In standard Java there are two ways to make GUIs: Swing and AWT.

To be short, Swing is platform-independent and AWT is platform-dependent. Typically you pick either AWT or Swing and stick to it. I believe Swing is the more popular choice today as it is easier to work with.

You can tell Swing code from AWT code by the fact that Swing component classes are prefixed with a J. For example Frame is AWT and JFrame is the Swing equivalent.

The Swing components inherit from the AWT components so a JFrame is a Frame.

Windows and Frames

Now the difference between Window and Frame  (and JWindow and JFrame respectively) is that a Window is a plain window without any decorations; no borders, no title bar, no window management buttons. A Frame is a Window with all these decorations. And I put emphasis on is a in the above as Frame actually inherits Window.

So the inheritance tree looks like this:

          lang.Object
              |
           awt.Component
              |
           awt.Container
              |
           awt.Window
              |
     +--------+-------+
     |                |
swing.JWindow      awt.Frame
                      |
                 swing.JFrame


To answer your question about which of the methods is better. Note that getWindows() is defined in Window and inherited by JWindow, Frame and JFrame. Calling getWindows() will get all windows, even owner-less dialogues and system windows associated with the application, regardless of if they have decorations or not. On the other hand getFrames() is defined in Frame so calling getFrames() will get all windows with decorations (frames). If your application doesn't have any frame-less windows, the two pieces of code you posted will be equivalent.

The Code

Your code is likely fine as it is wither either approach as plain Windows are kind of rare and often transient. The approach you're using is the standard one.

If you want to be absolutely sure you get every window there is and be picky about it, this is how I would write it:

for(Window window: Window.getWindows()) {
    SwingUtilities.updateComponentTreeUI(window);
}


For your reference, see the Java Docs for JWindow  and JFrame and their super classes.