Move setting of awtAppClassName from MainWindow to Main by neilcsmith-net · Pull Request #9314 · apache/netbeans

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net · 2026-03-31T17:34:30Z

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This should fix issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value that need to be worked around in the various package builds.

Follow up to discussion in #9303

mbien · 2026-03-31T20:52:41Z

+ if (xtoolkit.getName().equals("sun.awt.X11.XToolkit")) { //NOI18N
+ // TODO those add --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED
+
+ //#183739 / JDK-6528430 - provide proper app name on Linux
+ try {
+ final Field awtAppClassName = xtoolkit.getDeclaredField("awtAppClassName"); //NOI18N


i find it curious that the field isn't final -> we are lucky here since final might mean final in not too far future.
https://github.com/openjdk/jdk/blob/20c3082aac4381a5d38ed3abb34b3651b2d28e08/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L164
I think this is ok since it is only moving code around. But all those hacks have to go away. Every --add-opens flag we set is a red flag.

It's such a commonly used workaround that it's probably deliberately kept like that. An API or system property would be great for this, but it doesn't look like it's happening anytime soon! https://bugs.openjdk.org/browse/JDK-6528430 😄 This will also need consideration if/when there's a move from XWayland to Wakefield.
The only other workaround is to ensure the toolkit is initialized from the main thread, but that would lead to a shared WM_CLASS across all platform applications.

startup metrics for this:
getLocalGraphicsEnvironment() 23 ms
configureAWTAppClassName() 9 ms
i am wondering if this too could be queued onto EDT so that it executes before splash. The reason why this block existed seems to be (see comment above) to log a custom msg if JDK can't initialize graphics. This might not be a big concern anymore.

actually. discard that thought. First call to invokeLater() would have similar init paths.

Yes, had already had and discarded same thought for similar reason. 😆

Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net · 2026-04-07T09:16:04Z

Rebased and fixed (minor) conflict following merge of #9303

neilcsmith-net requested review from ebarboni, eirikbakke and mbien March 31, 2026 17:34

neilcsmith-net added Platform [ci] enable platform tests (platform/*) ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) labels Mar 31, 2026

neilcsmith-net marked this pull request as draft March 31, 2026 17:34

neilcsmith-net added this to the NB30 milestone Mar 31, 2026

mbien reviewed Mar 31, 2026
View reviewed changes

Move setting of awtAppClassName from MainWindow to Main
4025747
Move the setting of awtAppClassName for XToolkit into Main so that it is set before splash and import dialogs are created. This fixes issues with duplicate dock icons caused by incorrect WM_CLASS derived from this field value.

neilcsmith-net force-pushed the splash-wm-class branch from 7e18153 to 4025747Compare April 7, 2026 09:13

neilcsmith-net marked this pull request as ready for review April 7, 2026 09:14

neilcsmith-net requested a review from mbien April 7, 2026 09:15

mbien approved these changes Apr 7, 2026
View reviewed changes

neilcsmith-net merged commit ff736df into apache:masterApr 7, 2026
30 checks passed