Phoebus on Mac OS Monterey may crash

[georgweiss]

I have a user reporting Phoebus crashes on Mac OS Monterey. Possibly explained by https://bugs.openjdk.java.net/browse/JDK-8275723.

[kasemir]

Your link suggests it's fixed in OpenJFX18. Can you try that?
Release is only planned for March 2022, so not sure if we'd then wait for that or use a pre-release.

[georgweiss]

Well, 18-ea+6 seems to work on Catalina. I will set up a test on Monterey later this week.

[georgweiss]

My test user reports that 18-ea+6 works fine on Mac OS Monterey, no crashes seen. The feed-back I have is:

I've been exercising the software since last night, opening/closing many windows, running displays that are heavy consumers of waveform data.

However, the test user is using his private computer so I cannot ask for an extensive regression test.

[kasemir]

Good! Based on the JDK-8275723 info, there seems to be nothing we can do for a workaround, simply need to update JFX.
Do you want to wait for openjfx 18, maybe March 2022?
Wait for 17.0.2, early 2022?
Use 18-ea or 17.0.2-ea now?

[georgweiss]

Not sure I like the idea of using early access. My test user is fine using the test package I prepared.

So my vote is to wait until March 2022.

On a general note: is there a documented test procedure to do regression when we update JavaFX?

[kasemir]

is there a documented test procedure to do regression when we update JavaFX?

I'm not aware of one. What I do is open some beam line displays where certain 'dashboard' pages tend to use everything that there is. Could alternatively go through the example displays.
Plus open Applications, Display, 3D Viewer because that checks if ConditionalFeature.SCENE3D is supported.

[georgweiss]

Thanks.
I would be prepared to perform regression tests on Mac OS Catalina and Windows 10 if/when we decide to update.

In the meanwhile we should maybe add a line in the README to highlight this issue, e.g. "not yet ready for Mac OS Monterey".

[kasemir]

Well, we kind of are ready. We just don't want to do it. Since you have a user who needs it, why not create a 'jfx_18' branch? For now it changes the JFX dependency to 18-ea, and we don't merge it, but whoever needs to run on the latest Mac OS can use it. Once JFX 18 is released, we update to the released version and merge it.

[georgweiss]

Such a branch would need to be maintained if we want it to be reasonably in sync with master.

[georgweiss]

Will test JavaFX 18 as soon as it becomes available. Test environments:

• Windows 10
• Mac OS Monterrey and Catalina (do not have access to High Sierra)
• CentOS7 + xfce. No access to Gnome environment, unfortunately.

[georgweiss]

Based on test results and discussions, project has updated to JavaFX 18.