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 >
