<AWT Dev> [8] Review request for 8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m

[Anthony Petrov]

On 01/14/13 17:26, Anthony Petrov wrote:
> Hi Christopher,
>
> On 01/11/13 20:14, Christopher Deckers wrote:
>> I don't know if that helps the conversation, but just so nothing gets
>> omitted...
>>
>> If AWT knew SWT was going to run, we could probably not start our
>> own event loop. Do we want to support this use-case?
>>
>> I'm asking, because otherwise, i.e. if SWT is always initialized
>> first, then no matter where you start AWT (main thread or not), it
>> will run just fine re-using the existing SWT's event loop.
>>
>>
>> When AWT embeds SWT (to get the native web browser in a Swing
>> application for example), it is not uncommon to have the main method in
>> an AWT Component subclass (generally a JFrame). We had issues in the
>> past where on Mac this causes AWT to initialize certain stuff while
>> loading the AWT Component before main() is even invoked. As a workaround
>> we advised users to avoid placing their main() method (which will perfom
>> the SWT event loop) in an AWT subclass but I see users stumbling this
>> issue every now and then.
>
>
> If SWT runs the event loop (under normal circumstances), then in this
> case SWT embeds AWT, not vice versa. And you're normally running such
> apps with -XstartOnFirstThread, right?
>
>> Is this still going to cause problems on Mac? Isn't it going to trigger
>> AWT loading before SWT can be detected (the use case you described)?
>
> I'm not an expert in SWT, so I'll ask some questions. What kind of
> problems does this cause? I mean, if I do something like this:
>
> class MyFrame extends awt.Frame {
> static void main() {
> // init SWT first, then...
> // new MyFrame().setVisible(true);
> }
> }
>
> $ java -XstartOnFirstThread MyFrame
>
> Does this work today?

So, we have tested with a similar application, and it appears that AWT 
is able to start up and run in this case. In pseudo code this looks like:

main()
{
    new awt.Frame().setVisible(true);
    // Proceed with SWT
}

and running it with the -XstartOnFirstThread. Debugging reveals that the 
NSApplicationLoad() call in awt.m actually marks the app as running 
(i.e. [NSApp isRunning] will return YES afterwards) even though nobody 
is running an event loop yet.

So, I think we should still check this command line option in the AWT 
starter, and if it is present, do call the NSApplicationLoad() as 
before. I'll rework the fix and take into account this use case then.

It is still a mystery as to why isRunning returns YES after just calling 
the NSApplicationLoad() method. I can't find any specification stating that.

--
best regards,
Anthony



>
> With my proposed fix this will most likely break on the Mac. Therefore
> I'd like to know first if this is a supported use-case. What does SWT
> documentation say about that?
>
> We could think about ways to improve the situation, but if it doesn't
> work today, then we could do that later. Otherwise, I suppose I'll have
> to still check for -XstartOnFirstThread in awt.m and not start an event
> loop in this case.
>
> However, note that if MyFrame has a static initializer and performs some
> weird calls to AWT from it, then it might break as well because SWT
> hasn't started its event loop yet. I'm not sure if this can be improved,
> unless SWT agrees to live in the AWT's event loop. This is not directly
> related to my fix though, and I believe this doesn't work today anyway.
> But still thought I'd mention that.
>
> --
> best regards,
> Anthony