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?
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
