<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">John:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I know the discussion is about trying to detect thread misuse early on, as a way to help the application developers. I vaguely recall the discussion we had at some point about
adding the check to property invalidation code or some such, and the general consensus was that it might pose a compatibility risk or something along these lines.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Perhaps there is a place where such a check might be safely made (I don't know of any such place though)? We did, after all, step on the path of simplification (?) for the
sake of students (see <a href="https://openjdk.org/jeps/445">https://openjdk.org/jeps/445</a> ). Perhaps such a check could be hidden behind a system property so as not to break existing, if poorly written, applications.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Personally, I feel that it should be the first thing taught - always call FX from the FX application thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I am curious what other members of community think of this issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">John Hendrikx <john.hendrikx@gmail.com><br>
<b>Date: </b>Wednesday, August 7, 2024 at 12:01<br>
<b>To: </b>Andy Goryachev <andy.goryachev@oracle.com>, openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>[External] : Re: Detecting threading problems faster<o:p></o:p></span></p>
</div>
<p>Hi Andy,<o:p></o:p></p>
<p>Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit. I suspect that the PR below is one of those for
example, but there are likely many more.<o:p></o:p></p>
<p><a href="https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1123__;!!ACWV5N9M2RV99hQ!ILqOOB9ua4tDxfAV9pGPJJiQ3oXewiSQjH2BCsaQkhpgkHEQzT8hRQt2fb9mKjYbF24ZRpQwfEiELFvn4B28lBLwxrTE$">https://github.com/openjdk/jfx/pull/1123</a><o:p></o:p></p>
<p>Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack
traces provided will never point out the user code that may be the culprit. I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread...<o:p></o:p></p>
<p>--John<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">On 05/08/2024 17:01, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">John:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Can you cite a bug or give an example of such a problem?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe. It is possible that I use the system trivially
and not to the full extent. Both swing and javafx are single threaded by design. Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would
you want to do that?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev <a href="mailto:openjfx-dev-retn@openjdk.org">
<openjfx-dev-retn@openjdk.org></a> on behalf of John Hendrikx <a href="mailto:john.hendrikx@gmail.com">
<john.hendrikx@gmail.com></a><br>
<b>Date: </b>Sunday, August 4, 2024 at 16:30<br>
<b>To: </b><a href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a> <a href="mailto:openjfx-dev@openjdk.org">
<openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>Detecting threading problems faster</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">Hi list,<br>
<br>
I know of quite some bugs and users that have been bitten by the <br>
threading model used by JavaFX. Basically, anything directly or <br>
indirectly linked to an active Scene must be accessed on the FX thread. <br>
However, as FX also allows manipulating nodes and properties before <br>
they're displayed, there can be no "hard" check everywhere to ensure we <br>
are on the FX thread (specifically, in properties).<br>
<br>
Now, I think this situation is annoying, as a simple mistake where a <br>
Platform.runLater wrapper was forgotten usually results in programs <br>
operating mostly flawlessly, but then fail in mysterious and random and <br>
hard to reproduce ways. The blame is often put on FX as the resulting <br>
exceptions will almost never show the user code which was the actual <br>
culprit. It can result in FX being perceived as unstable or buggy.<br>
<br>
So I've been thinking if there isn't something we can do to detect these <br>
bugs originating from user code much earlier, similar to the <br>
`ConcurrentModificationException` the collection classes do when <br>
accessed in nested or concurrent contexts.<br>
<br>
I think it may be possible to have properties check whether they're part <br>
of an active scene without too much of an performance impact, possibly <br>
even behind a switch. It would work like this:<br>
<br>
Properties involved with Nodes will have an associated bean instance <br>
(`getBean`). This is an object, but we could check here if this <br>
instance implements an interface:<br>
<br>
if (getBean() instanceof MayBePartOfSceneGraph x) {<br>
if (x.isPartOfActiveScene() && !isOnFxThread()) {<br>
throw new IllegalStateException("Property must only be <br>
used from the FX Application Thread");<br>
}<br>
}<br>
<br>
This check could be done on every set of the property, and potentially <br>
on every get as well. It should be relatively cheap, but will expose <br>
problematic code patterns at a much earlier stage. There's a chance <br>
that this will "break" some programs that seemed to be behaving <br>
correctly as well, so we may want to put it behind a switch until such <br>
programs (or libraries) can be fixed.<br>
<br>
What do you all think?<br>
<br>
--John<br>
<br>
(*) Names of methods/interfaces are only used for illustration purposes, <br>
we can think of good names if this moves forward.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>