Hi Christopher,
On 1/14/2013 21:52, Christopher Deckers wrote:
Thanks for taking the time to answer. I did a bit of research to try to
answer as accurately as I could, and I uncovered buried knowledge about
AWT/SWT mixing which I added to my answer. Hopefully you can benefit
from it.
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?
From a user/developer point of view, they build a whole Swing
application, but somewhere an SWT Browser is going to be embedded. The
requirement is to use -startOnFirstThread and to run the SWT event pump
at the end of the main method. The other unofficial requirement on the
Mac JRE was to avoid placing the main method in an AWT Component subclass.
We found this issue first here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291705#c3
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291705#c6
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);
}
}
Well, this is the catch: it sorts of work but lots of bad things happen,
and these are not obvious errors to troubleshoot. For example, the SWT
bug report above hit it, as well as this one:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=344384#c3
$ java -XstartOnFirstThread MyFrame
Does this work today?
On Windows and Linux, yes. On Mac, sort of. Some users are happily using
that though they may one day get strange issues depending on what their
code does. Maybe some users are facing such issues but have absolutely
no idea about what is happening.
Right. But as I've indicated in a previous message, we've tested with a
similar test case, and it worked fine for us with my latest fix. Given
that SWT officially does not support this usage, I think we're fine with
our current implementation.
With my proposed fix this will most likely break on the Mac.
I wish this issue would either generate an exception/warning or just
work. Currently, with Mac JRE, this is silent and generates problems.
The root cause of all the troubles is that AWT won't start the event
loop since it expects SWT to start one. And if any operation requires to
execute something on the event loop synchronously and does that before
SWT has started, the app may lock or otherwise misbehave.
Note that I've filed 8006326 to develop a mechanism for several GUI
toolkits to co-exist in one JVM on Mac. My first version of the fix
proves that it is possible (in case AWT+FX). Once we provide a solution
for 8006326, and if SWT want to implement and support it too, then
everyone will be happy regardless of the order of toolkits'
initialization. But w/o proper support implemented on the SWT side, we
can't do much to help that, really.
Another important use case to consider: applets. Some people are using
SWT Browser in applets. On Windows and Linux this works fine, but on Mac
there used to be some issues. Eventually, we managed to get it to work
when using plugin2, and using (in reality, all done through reflection):
com.apple.concurrent.Dispatch dispatch =
com.apple.concurrent.Dispatch.getInstance();
java.util.concurrent.Executor executor =
dispatch.getNonBlockingMainQueueExecutor();
executor.execute(runnable);
One of the runnables is to find the SWT Display and another one is the
SWT event pumping. You can see for yourself all that we have to do to
support Mac:
https://github.com/Chrriis/DJ-Native-Swing/blob/master/DJNativeSwing-SWTCore/src/chrriis/dj/nativeswing/swtimpl/core/SWTNativeInterface.java
cf "runWithMacExecutor" line 647 and its usages in the class.
Because AWT is initialized first (Applet is a Component subclass), some
users cannot support Applets or have to avoid certain things that
trigger the bugs (finding this is empirical).
And related to that, I wonder how we are going to integrate with
applets, because I doubt "com.apple.*" is going to remain.
I'm not an expert in applets, but nobody's going to remove com.apple.*,
just yet at least. If you have a clear understanding of what exact APIs
you need in order to support your use cases, please file RFEs at
bugs.sun.com. We can consider them, and perhaps provide them in the form
of com.sun.* APIs or alike.
Note that applets on Mac JRE are not smooth sailing though. Some issues
also appeared when upgrading certain plugins (Flash), so in case you may
have the same issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=352168
From your discussion, you seem to compare JavaFX threading with SWT
threading, so how does JavaFX work with Applets?
Again, I'm not an expert in this area. From what I know, Java runs in a
separate process and communicates with the browser through the CALayer
machinery using some "NPApi events" to send GUI event from browser back
to the FX app. I believe that in Java/AWT applets work in a similar way.
This is unrelated to threading though. The models used by SWT and FX are
really different. SWT expects user code to get on the main thread itself
(usually by means of -XstartOnFirstThread) and run the SWT event loop
there. FX does it itself (as does AWT for example, and honestly, I don't
see why SWT can't do the same, but they don't...) Perhaps if they change
that, it might help resolve a lot of issues with using SWT on the Mac.
AWT (or FX) alone can't help much here unfortunately.
On a related note, Webstart does not have the issue because we can pass
platform specific definitions, and we can specify -XstartOnFirstThread
in the java-vm-args.
There's also com.apple.javaws.usingSWT system property, btw.
--
best regards,
Anthony
Therefore I'd like to know first if this is a supported use-case.
What does SWT documentation say about that?
As far as I know, nothing about it in any documentation.
We could think about ways to improve the situation, but if it
doesn't work today, then we could do that later.
Yes, of course. I was just giving a problematic use case that happens
because of wrong initialization order, in case this would affect the
current approaches you are working on.
We had many issues with Mac and I wonder how all that is going to work
with the new JDK. I have several users pinging me by e-mail to know if
it now works because the current situation is a nightmare for them. I am
also worried that when it starts to work we are going to have the same
issues that we had at the begining of proper SWT support in Mac JRE
(like duplicate menus in apple bar, no functional menus, problem with
dock, crash when zoomed, etc.)
I realize that I added several items to this discussion, so feel free to
split and answer with different topics if you want to continue the
discussions and keep things logicaly separate :)
Cheers,
-Christopher
