Crash when using UIManager.setLookAndFeel

[kirill-grouchnikov]

This is the simplest way to reproduce this:

public class Test {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(() -> {
            try {
                UIManager.setLookAndFeel(new WebLookAndFeel());
            } catch (Exception e) {
                e.printStackTrace();
            }
        });
    }
}

It crashes (version 1.2.12) with

java.lang.NullPointerException
	at com.alee.managers.style.AbstractComponentDescriptor.updateDefaults(AbstractComponentDescriptor.java:281)
	at com.alee.managers.style.StyleManager.registerComponentDescriptor(StyleManager.java:831)
	at com.alee.managers.style.StyleManager.initializeDescriptors(StyleManager.java:462)
	at com.alee.managers.style.StyleManager.initialize(StyleManager.java:265)
	at com.alee.managers.UIManagers.initialize(UIManagers.java:73)
	at com.alee.laf.WebLookAndFeel.initializeManagers(WebLookAndFeel.java:1065)
	at com.alee.laf.WebLookAndFeel.initialize(WebLookAndFeel.java:391)
	at java.desktop/javax.swing.UIManager.setLookAndFeel(UIManager.java:586)
	at Test.lambda$main$0(Test.java:9)

The same crash is observed when using UIManager.setLookAndFeel("com.alee.laf.WebLookAndFeel") or -Dswing.defaultlaf=com.alee.laf.WebLookAndFeel VM parameter

[husker-dev]

Can be fixed by this code before initialization:

UIManagers.initialize();

public class Main {

    public static void main(String[] args) {
        SwingUtilities.invokeLater(() -> {
            try {
                UIManagers.initialize();
                UIManager.setLookAndFeel("com.alee.laf.WebLookAndFeel");
            } catch (Exception e) {
                e.printStackTrace();
            }
        });
    }
}

(Not a solution, just my observation)

[husker-dev]

And so it seems to me that the problem is that initComponentDefaults in WebLookAndFeel class do not load on time

[kirill-grouchnikov]

It also works with just WebLookAndFeel.install(), but what I'm reporting here is that the main look-and-feel class crashes when it's used in one of the three traditional ways, without using any extra library-specific calls.

[mgarin]

That is really weird indeed...
I'll look into that, thanks for reporting!

[mgarin]

I've pushed a fix for this and new JUnit test for both initialization options.
It will be available in v1.2.13 update.