macos: reflective access by DarkLaf to constructor com.apple.laf.AquaLookAndFeel about darklaf

[DevCharly]

Tried also this solution in FlatLaf some days ago. This had some downsides. First was that FlatLaf.uninitialize() was invoked from within FlatLaf.initialize(). See stack trace:

Thread [AWT-EventQueue-0] (Suspended (breakpoint at line 165 in FlatLaf))	
	FlatLightLaf(FlatLaf).uninitialize() line: 165	
	UIManager.setLookAndFeel(LookAndFeel) line: 580	
	UIManager.setLookAndFeel(String) line: 633	
	FlatLightLaf(FlatLaf).getBase() line: 197	
	FlatLightLaf(FlatLaf).initialize() line: 115	
	UIManager.setLookAndFeel(LookAndFeel) line: 586	
	UIManager.setLookAndFeel(String) line: 633	
	DemoPrefs.initLaf(String[]) line: 69	
	FlatTestFrame.create(String[], String) line: 75	
...

Next problem was that the active LaF (UIManager.getLookAndFeel()) remains AquaLookAndFeel, but with UI default values from FlatLaf. This was a mess...

But there is a better solution. Since Java 9 there is a new method UIManager.createLookAndFeel(String) that allows creating installed LaFs by name.

This is what I'm using in FlatLaf now:

if( SystemInfo.IS_JAVA_9_OR_LATER ) {
    Method m = UIManager.class.getMethod( "createLookAndFeel", String.class );
    base = (BasicLookAndFeel) m.invoke( null, "Mac OS X" );
} else {
    base = (BasicLookAndFeel) Class.forName( UIManager.getSystemLookAndFeelClassName() ).newInstance();
}

This works fine without any warning.

BTW congrats to the great DarkLaf launch. 👍
Glad that you decided to continue DarkLaf. Swing needs good modern up-to-date LaFs. The more the better. And many thanks for mentioning FlatLaf in your reddit announcement.

[weisJ]

Shouldn't occur anymore.

[vlsi]

I'm not sure how often Jigsaw is used, however, I guess that would be an error in a modular application.

What do you think of getting the instance via UIManager.getLookAndFeel()?

[vlsi]

For instance:

final String systemLafClassName = UIManager.getSystemLookAndFeelClassName();
final LookAndFeel currentLaf = UIManager.getLookAndFeel();
if (systemLafClassName.equals(currentLaf.getClass().getName())) {
    if (currentLaf instanceof BasicLookAndFeel) {
        base = (BasicLookAndFeel) currentLaf;
    } else {
        base = new MetalLookAndFeel();
    }
} else {
   // Here can be a dance with UIManager.setLookAndFeel(systemLafClassName) + getLookAndFeel

    try (ReflectiveWarningSuppressor sup = new ReflectiveWarningSuppressor()) {
        final String name = UIManager.getSystemLookAndFeelClassName();
        base = (BasicLookAndFeel) Class.forName(name).getDeclaredConstructor().newInstance();
    }
}

[weisJ]

Yes this looks like a good solution. If --illegal-access=deny is used the current LaF could still be used as a fallback option with a warning that the LaF might not behave as intended.

[vlsi]

the current LaF

What I mean is the following sequence seems to comply with --illegal-access=deny:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
LookAndFeel systemLaf = UIManager.getLookAndFeel();

[weisJ]

Though a rather heavy operation probably the best solution. I checked the implementation of UIManager and changing the Laf inside the constructor doesn't interfere with the Laf installation.

[weisJ]

Thanks for the insight. Though the issue you are describing stems from initializing the base laf in LookAndFeel#initalize. Here the base laf is created in the constructor of DarkLaf, so it actually happens before initialize has been called.

BTW congrats to the great DarkLaf launch. 👍
Glad that you decided to continue DarkLaf. Swing needs good modern up-to-date LaFs.
The more the better. And many thanks for mentioning FlatLaf in your reddit announcement.

Thank you for the kind words :)