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.