<div dir="auto"><div>Hi Martin,<div dir="auto"><br></div>Jiri pushed this patch yesterday.<br><br><div class="gmail_quote"><div dir="ltr">Le mer. 3 oct. 2018 Ã  10:31, Martin Balao <<a href="mailto:mbalao@redhat.com">mbalao@redhat.com</a>> a Ã©crit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Laurent,</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 27, 2018 at 1:19 PM, Laurent Bourgès <span dir="ltr"><<a href="mailto:bourges.laurent@gmail.com" target="_blank" rel="noreferrer">bourges.laurent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Mario,</div><br><div><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>  Â  Â 1. Why is EDT_DAEMON_THREAD_POOL needed?<br>
> <br>
> <br>
> This is critical on OpenJDK 11 as SequencedEvent processing is buggy<br>
> (still not fixed).<br>
> - This specific Thread pool uses a specific factory to create threads in<br>
> main thread group (main thread).<br>
> <br>
> Â Â Â  public Thread newThread(Runnable r) {<br>
> Â Â Â Â Â Â Â Â Â Â Â  final Thread t = new Thread(MAIN_GROUP, r, ...<br>
> - Such particular thread then calls SwingUtilities.invokeXxx() methods,<br>
> making EDT/AWT use the proper main AppContext & EventQueue.<br>
> <br>
> Â Â Â  EDT_DAEMON_THREAD_POOL.submit(new Runnable() {<br>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  public void run() {<br>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  SwingUtilities.invokeLater(doRun);<br>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  }<br>
> Â Â Â Â Â Â Â Â Â Â Â  });<br>
> <br>
> This pattern allows to transfer any Swing / AWT invocations from any<br>
> running Thread (in or out the main Thread group) into the proper<br>
> AppContext, like a "priviledged" ITW GUI action.<br>
<br>
Yeah, but it's still ending up in the EDT, I'm puzzled as to what is<br>
different here than directly using invokeAndWait/invokeLater.<br></blockquote><div><br></div></span><div>It is related to Swing/Awt internals that associate awt.AppContext to one ThreadGroup:</div><div>in ITW, several thread groups are in use (application, security, main ...) so each thread group can have its own awt.AppContext, EventQueue and EventDispatcherThread as a consequence.</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>What would be the use-case that requires this "bridge"?<br></div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Typically all ITW internal dialogs (Security prompts, java console, splashscreen from netx) but never any swing/awt code from the application: it stays in its sandbox with its own jnlp classloader, security manager & AppContext.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>I suggest to revert this part of the changeset and further discuss it. In case that something were broken by reverting only this part, I suggest to put the whole patch on hold.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Let's test the patch integrated in ITW 1.7 and see if any security issue happens or let's discuss how to improve this patch.</div><div dir="auto"><br></div><div dir="auto">Jiri could also do a rollback.</div><div dir="auto"><br></div><div dir="auto">Laurent</div></div>