RFR: 8349091: Charts: exception initializing in a background thread [v6]

[Kevin Rushforth]

On Wed, 5 Mar 2025 15:47:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, using a custom property, or a wrapper, would solve this particular synchronization problem, although that wouldn't solve all of the problems. 
>> 
>> We would then be left with the problem that if the accessibility change listener did fire -- which necessarily happens on the FX app thread -- while the object was being set up on a background thread, the listener might try to modify properties that are being touched on the background thread. This is just another case of a more general problem we already have with animation, and which Andy fixed by not starting animation in a few places unless and until we are on the FX app thread.
>> 
>> So I think the solution Andy has chosen of deferring adding the listener is better than trying to fix the accessibility property, followed by fixing the listeners that use it, to be thread-safe.
>
> Thank you, @kevinrushforth .
> 
> Getting back to the rule of allowing Node construction from a background thread but not "use", should we consider enforcing the thread access rules for global and static objects (like Platform properties)?
> 
> In other words, constructing objects that might modify internal properties is ok, but trying to access shared objects is not?
> 
> (maybe it's time to move the discussion out of this PR into the mailing list perhaps?)

Enforcing the threading restriction when using properties is a larger conversation. If we want to have it, I agree it should be on the mailing list.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1981874992