[rfc] [icedtea-web] Fix EDT hanging on OpenJDK 11

[Laurent Bourgès]

Hi Mario,

Thanks for your feedback, here are my answers:

1. Why is EDT_DAEMON_THREAD_POOL needed?
>

This is critical on OpenJDK 11 as SequencedEvent processing is buggy (still
not fixed).
- This specific Thread pool uses a specific factory to create threads in
main thread group (main thread).

    public Thread newThread(Runnable r) {
            final Thread t = new Thread(MAIN_GROUP, r, ...
- Such particular thread then calls SwingUtilities.invokeXxx() methods,
making EDT/AWT use the proper main AppContext & EventQueue.

    EDT_DAEMON_THREAD_POOL.submit(new Runnable() {
                public void run() {
                    SwingUtilities.invokeLater(doRun);
                }
            });

This pattern allows to transfer any Swing / AWT invocations from any
running Thread (in or out the main Thread group) into the proper
AppContext, like a "priviledged" ITW GUI action.


> 2. In the previous code, there was a loop until
> "!splashScreen.isSplashImageLoaded()", your code is functionally
> different, other than just pushing things into the EDT, it also
> refactor this call. I'm not very familiar with the inner intricacies
> and I thought the previous call was redundant and only necessary due
> to the cross thread synchronisation, but I rather ask your intentions
> here that assume anything.
>

I agree I simplified that code as I did not catch any reason why it is so
complicated: I did not figure out any real reason to catch 2 times
(InterruptedException) in JNLPSplashScreen constructor +
setSplashImageURL() then loop on: while
(!splashScreen.isSplashImageLoaded()) => it simply does not make sense to
me.

Any idea, Jiri ?


> 3. It seems that methods that use "observable" are synchronized.
> However, the EDT will use "observable" and it's not synchronized. Is
> this safe?
>

Ok, fixed:
                synchronized(observable) {
                    if (observable.hasChanged() ||
(Boolean.TRUE.equals(force))) {
                        observable.notifyObservers(force);
                    }
                }

4. Restored ThreadCheckingRepaintManager with fixed license header as Jiri
requested

5. I fixed another bug in SecurityDialog.java:
    Closing a SecurityDialog by clicking on the window close [x] was
blocking the GUI:
+            public void windowClosed(WindowEvent e) {
+                // called if the user closes the window directly (dispose
on close)
+                // always dispose() to unlock message processing
+                getViwableDialog().dispose();
             }

Here is the updated patch:
http://cr.openjdk.java.net/~lbourges/itw/patch_EDT.log.5

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20180926/083e741a/attachment.html>