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

[Anthony Petrov]

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
>