The various platform-specific lookandfeels (e.g. motif, windows) should not be required if the app doesn't want them. They are not part of the swing.jar, yet the UIManager fails to initialize without them. This is especially true if I am making a seemingly innocous call to find out what lookandfeels are *available*, via UIManager.getAuxiliaryLookAndFeels()... this ends up going through the full UIManager initialization, and then forces the load of whatever l&f is specific to the platform I am on.

We ship with metal only and don't want to have to ship, have a classpath for, and load at runtime, "motif" or "windows" l&f.

Here is my output when I have a call to UIManager.getAuxiliaryLookAndFeels() in my code (running build4):

javalite: .../jag/apps/javaplan> ./runjp
java.lang.Error: can't load com.sun.java.swing.plaf.motif.MotifLookAndFeel
        at com.sun.java.swing.UIManager.initializeDefaultLAF(UIManager.java:547)
        at com.sun.java.swing.UIManager.initialize(UIManager.java:617)
        at com.sun.java.swing.UIManager.maybeInitialize(UIManager.java:625)
        at com.sun.java.swing.UIManager.getAuxiliaryLookAndFeels(UIManager.java:405)

Keep in mind, however, that this IS NOT A PROBLEM WITH UIManager.getAuxiliaryLookAndFeels()... it is a problem with your initialization methods.

Recently a "simple fix" was made to bug #4109150, to get "setLookAndFeel()" working. My guess is that the fix was simple because someone threw in the missing call to "UIManager.maybeInitialize()". Though that may make bug #4109150 go away, this bug remains, in that if I say "setLookAndFeel("com.sun.etc.etc.metal"), and I don't have *motif l&f* (on Solaris) in my classpath, then the "maybeInitialize()" call will raise, and no l&f will be able to ever be set.

For this same reason, even the workaround of calling "getLookAndFeel()" or "getAuxiliaryLookAndFeels()" in order to do the initialization, but catching the "motif not found" exception doesn't solve the problem because it still raises before the initialization is complete.

So, really you should not load *any* default l&f until specifically told to do so, or asked for the current one when there is none. And beyond that, when you are forced to load a default L&F, it needs to be one which is included as part of swing.jar... i.e. "metal".