On 25/04/2025 00:25, Christopher Schnick wrote:
>
> The custom wrapper solution to synchronize sounds like a good idea. I
> will experiment with that. Would it not also be a solution to add such
> a synchronized property wrapper class to JavaFX itself?
>
Yeah, it definitely could be, as long as it
The custom wrapper solution to synchronize sounds like a good idea. I
will experiment with that. Would it not also be a solution to add such a
synchronized property wrapper class to JavaFX itself?
The reason for why the expression helper replaces itself makes sense.
However, is that still a de
On 24/04/2025 22:07, Christopher Schnick wrote:
>
> Hey John,
>
> Thanks for taking your time on going into the details here.
>
> About our use case: We are actually not constructing UI in a
> background thread, all nodes are initialized and added to the scene on
> the platform thread. This is don
Hey John,
Thanks for taking your time on going into the details here.
About our use case: We are actually not constructing UI in a background
thread, all nodes are initialized and added to the scene on the platform
thread. This is done because previously instantiating nodes on other
threads w
remain the same: please don't. Always
> access JavaFX objects from the Application Thread.
>
>
>
> -andy
>
>
>
>
>
>
>
>
>
> *From: *openjfx-dev on behalf of Kevin
> Rushforth
> *Date: *Wednesday, April 23, 2025 at 11:41
> *To: *ope
In both cases only a partial fix can be applied that can ensure that at
a minimum the listener management doesn't get into a bad state. The
issue of what happens when a callback occurs on a second thread while
instances are being manipulated on the first thread will remain.
The partial fix would
Hi,
I don't think adding synchronized in ExpressionHelper is going to really
solve your problem. It will just move it elsewhere, but feel free to
let me know your exact scenario. For now I will make some assumptions.
I'm assuming you are constructing UI's in a background thread, and this
UI req
emain the same: please don't. Always
access JavaFX objects from the Application Thread.
-andy
*From: *openjfx-dev on behalf of Kevin
Rushforth
*Date: *Wednesday, April 23, 2025 at 11:41
*To: *openjfx-dev@openjdk.org
*Subject: *Re: ExpressionHelper thread-safety
This came up most recen
ehalf of Kevin Rushforth
Date: Wednesday, April 23, 2025 at 11:41
To: openjfx-dev@openjdk.org
Subject: Re: ExpressionHelper thread-safety
This came up most recently in the discussion of
https://github.com/openjdk/jfx/pull/1697
As noted by you and in that PR, properties are not thread-safe. I
John is replacing some of the ExpressionHelper uses (properties and
bindings) through https://github.com/openjdk/jfx/pull/1081. It's still
single threaded, but I think the new implementation there should be the
center point of this discussion.
On Wed, Apr 23, 2025 at 9:41 PM Kevin Rushforth
wrote
This came up most recently in the discussion of
https://github.com/openjdk/jfx/pull/1697
As noted by you and in that PR, properties are not thread-safe. If two
threads add a listener concurrently, or if one thread adds a listener
while and another thread notifies the listeners, it is likely to
11 matches
Mail list logo
