Bump to JavaFX 19.

[mikehearn]

Bumps to JavaFX 19. This is actually required for successful distribution to Windows, as far as I can tell (when the JVM is jlinked/bundled). I played with the sampler in a somewhat ad-hoc fashion and it all seemed to work.

I did more testing during this release and discovered something unfortunate - OpenJDK 17 is no longer really usable with JavaFX 17. The story is long and convoluted but basically it goes like this:

• On Windows C++ binaries depend on the Visual C++ runtime libraries. These libraries gain new features over time. They are backwards compatible, but, your app must have access to a recent enough version otherwise it won't start.
• OpenJDK was historically compiled with VS 2017. At some point this changed and it became compiled with VS 2019, increasing the version of the runtime DLLs needed. This also happened for point releases in already released major versions including 11 (questionable!). https://bugs.openjdk.org/browse/JDK-8242468
• JavaFX is compiled independently from OpenJDK. This introduced version skew which caused JavaFX to break when combined with new JDK releases because they upgraded their compiler for JavaFX 15: https://bugs.openjdk.org/browse/JDK-8281089
• This doesn't immediately cause problems if you use OpenJDK 17 + JavaFX 17.0.1/17.0.2 because then VC++ versions align. But, OpenJDK releases don't get updates and are abandoned after six months. So I switched to the Amazon JDK for this release. Amazon, it seems, still compile with VS 2017, they didn't follow the OpenJDK guys in the compiler upgrade yet. Therefore this skew is hit.
• They introduced a fix into JavaFX 19 that got backported to JavaFX 17.0.3 and JavaFX 11.0.15.
• Unfortunately, these versions of JavaFX are only available for download from Gluon with a support contract. The last JavaFX version they make available as jmods is 17.0.2.

Long story short, the path of least resistance is to go to Amazon JDK17 (up to date with security fixes etc), and JavaFX 19 (which isolates its DLLs from the JDK itself, resolving the conflicts).

The failure mode here is very tricky because most Windows machines have the new MSVC++ runtimes installed into c:\windows\system32 as various installers like to put them there, but a clean Windows 11 install does not have them. So this bug can show up on only very clean VMs that haven't been used for much yet. Quite annoying. I didn't notice this originally.

[mkpaz]

Thanks for the thorough review.
It was planned for the next major version anyway.