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

[Christopher Deckers]

Hi Anthony,

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.


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.


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.


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?

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.



> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130114/10210e00/attachment.html