Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New TrapExit implementation for 0.13.1 triggers AWT initialization #990

Closed
harrah opened this issue Nov 18, 2013 · 2 comments
Closed

New TrapExit implementation for 0.13.1 triggers AWT initialization #990

harrah opened this issue Nov 18, 2013 · 2 comments
Assignees
@harrah
Labels
Bug
Milestone
0.13.1

Comments

@harrah
Copy link
Member

harrah commented Nov 18, 2013

The new TrapExit implementation calls into the AWT subsystem even when AWT isn't used by user code. It isn't clear how it was avoided in the previous implementation, but it is important to fix because it causes focus loss on OSX.
@ghost ghost assigned harrah Nov 18, 2013
@harrah
Copy link
Member Author

harrah commented Nov 18, 2013

Related to #979.

harrah added a commit that referenced this issue Nov 18, 2013
@harrah
Fixes #989, #990. TrapExit jvm-independent and awt handling is only d…
f3c0509 
…one when awt is used.

SecurityManager.checkAccess(ThreadGroup) is specified to be called for every Thread creation
and every ThreadGroup creation and is therefore jvm-independent.  This can be used to get all
Threads associated with an application with good enough accuracy.

An application will be marked as using AWT if it gets associated with the AWT event queue thread.
To avoid unwanted side effects of accidental AWT initialization, TrapExit only tries to dispose
frames when an application is so marked.  Only one AWT application is supported due to a lack of
a way to associate displayed windows with an application.
@harrah
Copy link
Member Author

harrah commented Nov 18, 2013

Fixed in f3c0509.

@harrah harrah closed this as completed Nov 18, 2013
harrah added a commit that referenced this issue Nov 19, 2013
@harrah
Fixes #989, #990. TrapExit jvm-independent and awt handling is only d…
ba43d72 
…one when awt is used.

SecurityManager.checkAccess(ThreadGroup) is specified to be called for every Thread creation
and every ThreadGroup creation and is therefore jvm-independent.  This can be used to get all
Threads associated with an application with good enough accuracy.

An application will be marked as using AWT if it gets associated with the AWT event queue thread.
To avoid unwanted side effects of accidental AWT initialization, TrapExit only tries to dispose
frames when an application is so marked.  Only one AWT application is supported due to a lack of
a way to associate displayed windows with an application.
harrah added a commit that referenced this issue Mar 21, 2014
@harrah @eed3si9n
Fixes #989, #990. TrapExit jvm-independent and awt handling is only d…
68da0a5 
…one when awt is used.

SecurityManager.checkAccess(ThreadGroup) is specified to be called for every Thread creation
and every ThreadGroup creation and is therefore jvm-independent.  This can be used to get all
Threads associated with an application with good enough accuracy.

An application will be marked as using AWT if it gets associated with the AWT event queue thread.
To avoid unwanted side effects of accidental AWT initialization, TrapExit only tries to dispose
frames when an application is so marked.  Only one AWT application is supported due to a lack of
a way to associate displayed windows with an application.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@harrah harrah

Labels
Bug
Projects
None yet
Milestone
0.13.1
Development

No branches or pull requests
1 participant
@harrah