Hi Alexey, thanks for the correction. I've updated the commit message and PR title to JDK-8341144.
Thanks, Marco Il giorno mar 9 giu 2026 alle ore 18:06 Alexey Ivanov <[email protected]> ha scritto: > > Hi Marco, > > JDK-8035556 in the subject line of this thread and the PR is unrelated > to SystemTray/TrayIcon. > > In the body of your first email, you mentioned the correct JBS issue: > JDK-8341144. > > Could you amend the PR subject? > > -- > Regards, > Alexey > > On 2026-06-09 15:57, Marco Matessi wrote: > > Hi Phil, > > > > thanks for the quick feedback. I've opened a draft PR: > > https://github.com/openjdk/jdk/pull/31439 > > > > Looking forward to your review. > > > > Thanks, > > Marco > > > > Il giorno ven 5 giu 2026 alle ore 21:16 Philip Race > > <[email protected]> ha scritto: > >> Hi, > >> > >> In principle, this all sounds great. > >> This is a problem people have complained about but we've not got far in > >> figuring out what to do. > >> I don't have any view at this early stage on your question about using a > >> shared connection. > >> > >> The main concerns I'd have are > >> 1) Whether the SNI operates in conformance with the specification for > >> SystemTray/TrayIcon. > >> 2) Using FFM would mean it could not be backported to JDk21u .. but that > >> is a secondary concern. > >> If the work is done and functional, a motivated person could convert to > >> JNI for that. > >> > >> I suggest the next step is to create a DRAFT PR against JDK mainline. > >> That will be easier for us to review and try it out before you spend > >> time on polishing it. > >> > >> -phil > >> > >> > >> On 6/3/26 5:14 AM, Marco Matessi wrote: > >>> Hello, > >>> > >>> I'm Marco Matessi. This is my first OpenJDK contribution; I have > >>> signed the OCA. I've > >>> put together an implementation for JDK-8035556 and would like feedback > >>> on the approach > >>> before opening a formal RFR. > >>> > >>> The problem: on Ubuntu 24 and modern Wayland/GNOME desktops the legacy > >>> X11 XEmbed > >>> system tray protocol is no longer supported, so java.awt.TrayIcon is > >>> effectively broken > >>> there (see also JDK-8341144, PR #23329, which skips the test on > >>> Wayland). The de facto > >>> standard on current Linux desktops is the StatusNotifierItem (SNI) > >>> D-Bus protocol used > >>> by KDE, GNOME Shell extensions and AppIndicator. > >>> > >>> What I've done: a working SNI peer implemented over D-Bus. When > >>> org.kde.StatusNotifierWatcher is present on the session bus, > >>> TrayIcon/SystemTray > >>> delegate to the SNI peer; otherwise they fall back to the existing X11 > >>> XEmbed peer. > >>> XToolkit.createTrayIcon/createSystemTray/isTraySupported dispatch on that > >>> basis. > >>> > >>> The D-Bus layer uses Panama FFM (java.lang.foreign) against > >>> libdbus-1.so.3, with no > >>> new JNI code and no new native build artifacts. New classes live in > >>> sun.awt.X11: > >>> SNIDBusLib (FFM bindings), SNIMsg (DBusMessage wrapper), SNIDBusConn > >>> (session > >>> connection + dispatch loop), SNITrayIconPeer (org.kde.StatusNotifierItem + > >>> com.canonical.dbusmenu) and SNISystemTrayPeer. The dispatch loop runs on > >>> its own > >>> platform thread, independent of the GTK L&F. > >>> > >>> Why FFM rather than GDBus/JNI: > >>> - It follows the declared direction away from JNI toward Panama FFM; new > >>> C in > >>> libawt_xawt would go the other way. > >>> - libdbus-1 is not deprecated. GDBus is a wrapper over it, not a > >>> replacement. > >>> - SystemTray should not depend on the Look&Feel; a GDBus/GTK path > >>> would force GTK > >>> init even for Metal/Nimbus apps. > >>> - dbus_bus_get_private yields a separate connection, so there's no > >>> GMainLoop conflict > >>> with any GTK-internal D-Bus usage. > >>> > >>> The implementation has been built and tested on Ubuntu 24.04 (GNOME, with > >>> the > >>> AppIndicator shell extension) and includes three jtreg regression tests > >>> (SNITrayIconTest, SNITrayIconPropertiesTest, SNIFallbackTest). > >>> > >>> Two open items I'd like input on: currently there is one private > >>> connection and one > >>> dispatch thread per peer; a singleton shared connection is cleaner and > >>> I'll implement > >>> it based on feedback. SNITrayIconPeer is ~850 lines and I plan to split > >>> out an > >>> SNIDBusMenu class. > >>> > >>> Code (fork, branch JDK-8035556): https://github.com/basix86/jdk > >>> > >>> I'd appreciate any guidance on the overall approach. > >>> > >>> Thanks, > >>> Marco Matessi >
