Hi Philip, Sorry for the late reply, and thank you for pointing this out.
This is my first contribution and I wasn't fully aware of the scope of the Interim AI Policy. I used AI as an assistant to support my work, and I deliberately kept the Co-Authored-By line in the commit message to be as transparent as possible. I honestly believed that using AI as a support tool was allowed. I now understand that the policy does not allow AI-generated content in contributions, regardless of how it is used. I have now closed the pull request (#31439). I'm not in a position to rewrite the whole implementation by hand on my own right now, so I won't be resubmitting it at this time. That said, I'm still interested in the feature and open to collaborating if someone would like to work on it with me in the future. I hope the underlying issue (JDK-8035556) is still useful to keep on record, in case someone is able to take it forward. Thanks again, Marco Il giorno mer 10 giu 2026 alle ore 18:39 Philip Race <[email protected]> ha scritto: > > Hi, > > A problem with this has been pointed out. > > > https://github.com/openjdk/jdk/pull/31439/changes/a6ab4da826664d38c5f9b7bbb95c617e816dc555 > > Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> > > > That link isn't working for me but I do see > > "basix86 and claude committed 10 hours ago" > > And yet you checked the box that says "I confirm that I make this > contribution in accordance with the OpenJDK Interim AI Policy." > > If you read that : https://openjdk.org/legal/ai > > It says in part that > "Contributions in the OpenJDK Community must not include content generated, > in part or in full, by large language models, diffusion models, or similar > deep-learning systems. Content, in this context, includes but is not limited > to source code, text, and images in OpenJDK Git repositories, GitHub pull > requests, e-mail messages, wiki pages, and JBS issues." > > Using Claude *AT ALL* for this contribution contravenes this policy. > > Please read it, and understand it. > > For now you will have to withdraw the PR. We can't even look at this code. > > If you can create a version where there is NO AI GENERATED CODE WHATSOEVER, > then submit that. > > -phil. > > > On 6/9/26 7:57 AM, 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 > >
