<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Andy,</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.</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/jfx/pull/1123">https://github.com/openjdk/jfx/pull/1123</a></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...<br>
</p>
<p>--John<br>
</p>
<div class="moz-cite-prefix">On 05/08/2024 17:01, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<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"">Can
you cite a bug or give an example of such a problem?<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"">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?<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>
<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 class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> on behalf of John
Hendrikx <a class="moz-txt-link-rfc2396E" 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 class="moz-txt-link-abbreviated" href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>Detecting threading problems faster<o:p></o:p></span></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.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>