Java bug: getSystemLookAndFeelClassName() returns Metal, not GTK

[David Nemeskey]

Binary package hint: sun-java6-jdk

When using the UIManager.getSystemLookAndFeelClassName() method, it returns javax.swing.plaf.metal.MetalLookAndFeel (the cross-platform one), and not com.sun.java.swing.plaf.gtk.GTKLookAndFeel, as expected. If the UIManager.setLookAndFeel() method is called with the latter, the L&F will be set to GTK, so it is definitely there; the system just fails to recognize it as the default L&F.

This error is reproducible with sun-java5-jdk as well; I have not tried the -jre packages or gcj. Both the <jdk root>/bin/java and <jdk_root>/jre/bin/java works alike.

I am using Kubuntu 7.04.

[Matthias Klose (doko)]

please recheck with gutsy, this appears to be fixed at least with the Gnome desktop

[David Nemeskey (nemeskeyd)]

No, it's still the same (under KDE).

[Richard Laager (rlaager)]

This seems to work for me in Hardy in GNOME.

Here's a test program (save as HelloWorldApp.java, run "javac HelloWorldApp.java", then run "java HelloWorldApp"):

import javax.swing.UIManager;
class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println(UIManager.getSystemLookAndFeelClassName());
    }
}

[David Nemeskey (nemeskeyd)]

The bug is definitely still NOT fixed in Kubuntu Hardy. I believe that it's working in Gnome, but not in KDE.

The output of Richard's program is javax.swing.plaf.metal.MetalLookAndFeel under Kubuntu.

I also find kind of strange that the bug has been "fixed" on the same day as it was confirmed by Mr Nobody (see, no one is assigned to it). Can I reopen it, or should I open another one?

[Thomas Hotz (thotz-deactivatedaccount)]

Hardy is EOL. Is this still an issue for you? Thank you for telling us!

[David Nemeskey (nemeskeyd)]

It is still an issue in 12.04. The following program:

import javax.swing.UIManager;

public class Test {
    public static void main(String[] args) {
        System.out.println("System: " + UIManager.getSystemLookAndFeelClassName());
        System.out.println("CrossPlatform: " + UIManager.getCrossPlatformLookAndFeelClassName());
        for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels())
            System.out.println("Installed: " + laf);
    }
}

prints

System: javax.swing.plaf.metal.MetalLookAndFeel
CrossPlatform: javax.swing.plaf.metal.MetalLookAndFeel
Installed: javax.swing.UIManager$LookAndFeelInfo[Metal javax.swing.plaf.metal.MetalLookAndFeel]
Installed: javax.swing.UIManager$LookAndFeelInfo[Nimbus com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel]
Installed: javax.swing.UIManager$LookAndFeelInfo[CDE/Motif com.sun.java.swing.plaf.motif.MotifLookAndFeel]
Installed: javax.swing.UIManager$LookAndFeelInfo[GTK+ com.sun.java.swing.plaf.gtk.GTKLookAndFeel]

As you see, the system LaF is still Metal. Under Gnome, it is GTK.

I am aware that for KDE, a QtLookAndFeel would be the best match, but since no such thing exist, UIManager.getSystemLookAndFeelClassName() should default to GTK as the closest match (especially since by default, KDE sets the GTK style to QtCurve and the fonts to the ones used by KDE applications).

[Thomas Hotz (thotz-deactivatedaccount)]

Ok, i mark this bug as confirmed. Maybe you could file this bug upstream in Java?