JDK-8005465 : [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2012-12-25
  • Updated: 2014-10-15
  • Resolved: 2013-01-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.
7u40Fixed 8 b75Fixed
The JNI_OnLoad() function of the AWT dynamic library verifies whether it is running on the Cocoa thread, and if so, requires the -XstartOnFirstThread command line option to be specified by the user on the command line. This makes it difficult to initialize AWT after an FX application has already been started. See http://javafx-jira.kenai.com/browse/RT-20784

Since the code in awt.m is actually able to handle both cases, we should evaluate whether this check is needed in the first place, and possibly remove it.
noreg-hard: to use AWT together with the -XstartOnFirstThread option, a 3rd party GUI toolkit should be running in the Java process (e.g. SWT, or FX). Therefore, it is hard to write a good regression test for this issue that wouldn't depend on any external libraries.

@Phil: this is a valid point. However, the fix is not as benign as we thought initially. We need to test it in JDK 8 first. After that we could port it to 7u12 or 7u14, depending on how much time it will take to test it thoroughly.

Sent for review at: http://mail.openjdk.java.net/pipermail/awt-dev/2012-December/004018.html

Fully aware of that but the 7 fix is needed unless SQE can be convinced to move all FX 8 testing onto JDK 8 sooner rather than later. It also implies that some,maybe most, FX developers need to start using interim JDK 8 builds too. So a fix on 7u12 gives people another option.

JavaFX 8.0 is supposed to work with JDK 8.0 only. There's no a requirement for FX 8 to ultimately work with 7uX. Currently we don't plan on fixing this issue for 7uX release. We may back-port the fix later, after it's well tested with JDK / FX 8 first.

Since the JavaFX is built and tested with released version of the JDK (presently JDK 7). It is important that this problem gets fixed in the JDK first. The JavaFX Printing feature RT-17383, which is a critical feature of JavaFX 8.0, needs this fix ASAP (by JDK 7u12 time frame).