<AWT Dev> [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread

Anthony Petrov anthony.petrov at oracle.com
Thu Jul 11 04:22:31 PDT 2013

The fix still looks fine to me.

best regards,

On 07/11/13 06:13, Leonid Romanov wrote:
> On Jul 9, 2013, at 6:38 PM, Artem Ananiev<artem.ananiev at oracle.com>  wrote:
>> On 7/8/2013 8:35 PM, Leonid Romanov wrote:
>>> I encountered the case of unset handlerContext while testing SwingSet3 Web Start app.  It is triggered by selecting SwingSet3->About from the global menu bar. Since SwingSet3 doesn't use eAWT, it doesn't register any handlers, so selecting "About" menu item just shows standard Cocoa About dialog. In the code, it is accomplished by the following snippet from   _AppEventDispatcher.dispatch:
>>>              if (localHandler == null) {
>>>                 performDefaultAction(event);
>>>              } else {
>>>                  performUsing(localHandler, event);
>>>              }
>>> _AppEventDispatcher.performDefaultAction() is an abstract method, implemented in _AboutDispacther (shows native about dialog ) and _QuitDispatcher (quits the app). So, in order to display default About dialog we have to do the dispatching, even though handlerContext hasn't been set.
>> Do I get it right, that About and Quit menu handlers are implemented in eAWT code, not in the application code, and in these and only these cases we call performDefaultAction() instead of performUsing()? Could we then write it the following way:
>>>      // handler hasn't been set
>>>      if (handlerContext == null) {
>>>          performDefaultAction(event);
>>>      } else {
>>>          SunToolkit.invokeLaterOnAppContext(handlerContext, r);
>>>      }
> Yes, you are right. Done. I've also cleared /_AppEventHandler._AppEventMultiplexor code a bit. Here is the new webrev:
> http://cr.openjdk.java.net/~leonidr/8020038/webrev.01/

More information about the awt-dev mailing list