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

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

The fix still looks fine to me.

-- best regards, Anthony

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 macosx-port-dev mailing list