JDK-8090353 : Glass needs life cycle API
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2011-06-15
  • Updated: 2018-09-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8114141 - Mac: PuzzlePieces sample java crashes on window close
Relates :  
JDK-8114065 - Mac: need workaround for crash / hang on exit issues
Description
This is a clone of the original issue which was caused by Glass trying to access main Java env after the main Java thread has been already detached.

The original problem was fixed by explicitly checking for the main Java env at the specific code location that was causing the problem, however, the issue potentially exists for all Glass APIs. The way to address it is to assert that the main Java thread is still attached at the time we try to retrieve it, and if it is not available, then we can throw Java exception on the calling thread to notify that things are really really wrong.
Comments
I still get regular crashes on Mac (nearly every run). I haven't yet run with the latest from b36, but will do so.
07-07-2011
We might need to raise the priority of this issue. Unless Prism (Glass client) doesn't bother to make sure not to use Glass after it shuts it down, Glass needs to step in and do it for the client. Otherwise we'll keep getting sporadic crashes and failed lockFocus messages.
05-07-2011
Glass team discussion has occurred regarding this topic and it feels to me like we need to introduce a new life cycle APIs to Glass in order to handle this bug. The original crash has been addressed and at this point I feel comfortable to lower the priority of this bug until Glass team has a chance to flesh out the Glass lifecycle APIs.
21-06-2011
And this while running Ensemble: 2011-06-15 12:17:03.701 java[54777:d503] *** Assertion failure in -[GlassView3D lockFocus], /SourceCache/AppKit/AppKit-1038.35/AppKit.subproj/NSView.m:5237 2011-06-15 12:17:03.703 java[54777:d503] lockFocus caught exception: -[GlassView3D(0x100152c90) lockFocus] failed with window=0x10012db70, windowNumber=13754, [self isHiddenOrHasHiddenAncestor]=0 Glass detected outstanding Java exception at _GlassTimerTask:/Volumes/stuff/work/jfx/glass/glass-mat-lib-macosx/src/com/sun/mat/ui/GlassTimer.m:48 Exception in thread "Glass Timer Thread" java.lang.RuntimeException: Main Java thread is detached. at com.sun.glass.ui.mac.MacApplication._postOnEventQueue(Native Method) at com.sun.glass.ui.Application.postOnEventQueue(Application.java:184) at com.sun.javafx.tk.quantum.QuantumToolkit$11.run(QuantumToolkit.java:308) BUILD SUCCESSFUL (total time: 15 seconds)
15-06-2011
The new mechanism caught this: Glass detected outstanding Java exception at _GlassTimerTask:/Volumes/stuff/work/jfx/glass/glass-mat-lib-macosx/src/com/sun/mat/ui/GlassTimer.m:48 Exception in thread "Glass Timer Thread" java.lang.RuntimeException: Main Java thread is detached. at com.sun.glass.ui.mac.MacApplication._postOnEventQueue(Native Method) at com.sun.glass.ui.Application.postOnEventQueue(Application.java:184) at com.sun.javafx.tk.quantum.QuantumToolkit$11.run(QuantumToolkit.java:308) so it looks like it will be useful and works.
15-06-2011
This clone was filed to cover adding a new mechanism for checking whether main Java thread has been detached. This is very important since Glass is supposed to be used in multithreaded environment, so there might be many cases of Glass clients trying to use Glass APIs that require main Java thread to exist, even after it was already detached. This is an edge scenario, but we should be prepared. All we need is to throw a Java exception on the calling (nonmain) thread if main Java thread has been detected to be already detached.
15-06-2011