JDK-8011686 : [macosx] AWT accidentally disables the NSApplicationDelegate of SWT, causing loss of OS X integration functionality
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u17,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2013-04-08
  • Updated: 2014-10-15
  • Resolved: 2013-04-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u40Fixed 8 b89Fixed
Description
If the AWT native code (in awt.m) is loaded after SWT (or any other toolkit) has initialized its custom NSApplication subclass, AWT does not create its own NSApplicationDelegate (which might be ok). Instead AWT (by accident?) removes the currently installed app delegate. Effectively it does [NSApp setDelegate: nil]. This causes SWT apps to lose OS X integration functionality. Many bugs likely caused by this has been filed on both SWT and the JDK. I will add them to this bug as I find them. Note that this bug does not happen with Apple's JDK 6.

There is a trivial fix to this (don't call setDelegate: with nil), that certainly will improve things.

However, since at least SWT tries to obtain the AWT app delegate, and delegates certain methods to it (as well as handling them itself), maybe the AWT app delegate should be created, but just not installed using setDelegate:. Comments in [ApplicationDelegate sharedDelegate] suggests that this was the intent. But in this case, the logic in [ApplicationDelegate init] should likely be revised so that it acts more like if usingDefaultNib was NO by default, but perhaps not completely. This might be tricky and likely more suitable for a general overhaul like suggested in JDK-8006326.

This bug affects Java Mission Control which is Eclipse/SWT based (but has plug-ins using AWT), and is scheduled for inclusion in later JDK 7 updates as well as in JDK 8.
Comments
The fix only affects SWT, so it's hard to create a regression test.
22-08-2013
Since we have the SQE - OK for 7u40 - I will approve this request.
20-06-2013
In 7u40 we have a specific check for headless mode when setting the delegate. We do not have one in JDK8 because currently we do not load libawt_lwawt.dylib in headless mode in 8. These differences are tracked by another issues: (JDK-2224144 and JDK-2226108).
19-06-2013
SQE: OK to 7u40. Interesting that 7u40 before the fix works properly started on the first thread in an ssh session. It tries and fails to initialize headless mode and perhaps does not overwrite this delegate. I don't think an application would work reliably though.
19-06-2013
The offending code is in src/macosx/native/sun/awt/awt.m, in the implementation of [AWTStarter start:], near the end. The surrounding code differs between JDK 7 and JDK 8 master, but the culprit is always: OSXAPP_SetApplicationDelegate([ApplicationDelegate sharedDelegate]); This should be replaced with something like: id <NSApplicationDelegate> delegate = [ApplicationDelegate sharedDelegate]; // Only set the delegate if non-nil, to prevent removing an existing delegate from another toolkit, like SWT. if (delegate) { OSXAPP_SetApplicationDelegate(delegate); }
08-04-2013
A symptom of this bug (since the SWT app delegate does not receive applicationShouldTerminate:) JI-9000562 (originally https://bugs.eclipse.org/bugs/show_bug.cgi?id=399091 )
08-04-2013