Details
-
Bug
-
Resolution: Fixed
-
P3
-
11, 14
-
b12
-
linux
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8265533 | 15.0.4 | Yuri Nesterenko | P3 | Resolved | Fixed | b01 |
JDK-8265734 | 13.0.8 | Yuri Nesterenko | P3 | Resolved | Fixed | b01 |
JDK-8271066 | 11.0.13-oracle | Pankaj Bansal | P3 | Resolved | Fixed | b04 |
JDK-8266535 | 11.0.12 | Ramanand Patil | P3 | Resolved | Fixed | b02 |
Description
with the removal of this GNOME_DESKTOP_SESSION_ID variable, how should Java, moving forward detect a Gtk-based desktop?
For Example:
System.out.println(UIManager.getSystemLookAndFeelClassName());
- On Fedora 32, it returns: (ACTUAL): javax.swing.plaf.metal.MetalLookAndFeel
- On Fedora 27, it returns: (EXPECTED): com.sun.java.swing.plaf.gtk.GTKLookAndFeel
This issue is discussed in details here: https://github.com/AdoptOpenJDK/openjdk-support/issues/94
Note: As per the latest updates received from GNOME, using the above environmental variable is a bug. And the recommendation is that Java GUI apps running on Linux (and probably all Unix platforms) should use whichever "look and feel" is considered to be high-quality and doesn't look hugely out-of-place.
Attachments
Issue Links
- backported by
-
JDK-8265533 UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
-
- Resolved
-
-
JDK-8265734 UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
-
- Resolved
-
-
JDK-8266535 UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
-
- Resolved
-
-
JDK-8271066 UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
-
- Resolved
-
- relates to
-
JDK-8266713 [AIX] Build failure after 11u backport of JDK-8247753
-
- Resolved
-
- links to
-
Commit openjdk/jdk13u-dev/6389acfa
-
Commit openjdk/jdk15u-dev/a44e891d
-
Review openjdk/jdk13u-dev/188
-
Review openjdk/jdk15u-dev/27