Mike, Steve, Scott,
Thanks a lot for your comments! I conclude that SWT is OK to go with
this fix.
All,
Please note the change in the subject line: we're now targeting this fix
for 7u4. We really want to push it as is into 7u4. Please review at:
http://cr.openjdk.java.net/~anthony/7u4-11-fxHang-7159266.0/
We can re-work this fix for 7u6 if:
a) there's real use cases for headless AWT + eAWT API usage. Personally,
I doubt there's any, but let's see, AND
b) we find a better solution for this problem.
However, right now we really need this fix pushed because otherwise the
FX software rendering pipline is unusable on the Mac with 7u4.
Thanks in advance for your reviews!
--
best regards,
Anthony
On 4/5/2012 7:23 PM, Anthony Petrov wrote:
On 04/05/12 19:07, Mike Swingler wrote:
Please review a fix for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at:
http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/
With this fix we avoid setting an application delegate when AWT is
started in the headless mode. This prevents a hang when another GUI
toolkit (e.g. JavaFX) is already running in the same Java process.
This would logically mean that you won't get eAWT events (file open,
quit, etc) while started in this mode. Does this impact SWT as well?
In the headless mode an application doesn't have any UI, and as such
there's no way to generate e.g. a Quit action. Hence the application
delegate isn't necessary in this mode.
SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is
different from the headless mode. In the SWT mode the delegate will
still be installed.
I think this may not work in case of running an SWT application together
with the AWT in headless mode. However, I can't imagine who might want
to run SWT/AWT in such configuration because the headless mode is
supposed to be primarily used in server environments where a display is
physically unavailable, in which case SWT wouldn't be able to run there
either.
--
best regards,
Anthony
