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

[vlsi]

WARNING: Illegal reflective access by com.github.weisj.darklaf.DarkLaf (file:/Users/vladimirsitnikov/Documents/code/darklaf/core/build/classes/java/main/) to constructor com.apple.laf.AquaLookAndFeel()
	at com.github.weisj.darklaf.DarkLaf.<init>(DarkLaf.java:69)
	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:166)
	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:404)
	at java.base/java.lang.Class.newInstance(Class.java:591)
	at java.desktop/javax.swing.UIManager.setLookAndFeel(UIManager.java:633)
	at com.github.weisj.darklaf.LafManager.install(LafManager.java:172)
	at ui.ComponentDemo.lambda$showDemo$0(ComponentDemo.java:41)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

:(

[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.

[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]

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 :)