<AWT Dev> Review request for 7132692: [macosx] Class com.apple.eawt not functioning

Anthony Petrov anthony.petrov at oracle.com
Thu Feb 16 04:30:16 PST 2012


Hi Artem,

Thanks for taking a look at the fix.

On 02/16/12 14:32, Artem Ananiev wrote:
> On 2/14/2012 5:25 PM, Anthony Petrov wrote:
>> Could anyone please review the fix?
>
> I'm not the right person to review, so probably a stupid question. In
> AWTStarter -start:swtMode:swtModeForWebStart method, if onMainThread is
> YES, we call [st starter:args]. It in turn synchronously calls
> [NSApplicationAWT runAWTLoopWithApp: app], which should never return. So
> when the application delegate set in this case?

If onMainThread is YES, then we must be running in the swt_compatible 
mode (see a check for this at line 430). In this case AWT must be 
initialized only *after* SWT has started its event loop. Indeed, how 
else could we possibly start AWT from the main thread if there were not 
an event loop spinning yet?

This leads to the [app isRunning] returning YES at line 356, and as such 
we don't start up our own event loop but rather follow the 'else' branch 
of the if statement, and subsequently return from -starter:. After that 
the +start: will install our application delegate correctly.

--
best regards,
Anthony

>
> Thanks,
>
> Artem
>
>> --
>> best regards,
>> Anthony
>>
>> On 2/13/2012 6:53 PM, Anthony Petrov wrote:
>>> Hello,
>>>
>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132692
>>> at:
>>>
>>> http://cr.openjdk.java.net/~anthony/x-16-eawt-7132692.0/
>>>
>>> With this fix we postpone the initializing of an instance of the
>>> ApplicationDelegate class and setting the delegate to the NSApp until
>>> after the application itself has been fully initialized. The
>>> QueuingApplicationDelegate in libosxapp.dylib will queue all incoming
>>> notifications and resend them to the real ApplicationDelegate once
>>> it's installed.
>>>
>>> Note that it is still not completely clear to me why we must postpone
>>> creating the delegate. It seems that it may be somehow related to
>>> loading the nib file which is happening in NSApplicationAWT
>>> -finishLaunching: method.
>>>
>>> Given that:
>>>
>>> 1) the QAD ensures we don't miss any notifications,
>>> 2) the test application starts working correctly after this patch
>>> (i.e. the About, Preferences, and Quit menu items generate the
>>> expected eawt events), and
>>> 3) there doesn't appear to be an obvious requirement for the
>>> ApplicationDelegate to be initialized earlier,
>>>
>>> I consider this fix is OK. Also, it seems that the fix resolves
>>> 7130377 ([macosx] Adding Preferences menu results in NPE) as well.
>>>
>>> --
>>> best regards,
>>> Anthony


More information about the macosx-port-dev mailing list