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
