Upgrade openjfx to 17

[jsotuyod]

Running on Mac OSX with a version of JavaFX older than 14 produces garbled text as shown below.

In #53 we introduce a check to avoid running unsupported JavaFX versions under Mac OSX, but that currently means it's only possible to develop under Mac OSX by manually changing the referenced JavaFX libraries.

Bumping org.openjfx to 14.0.2.1 fixes this, but unfortunately introduces a number of new issues.

Firstly, the first test to use CodeArea will fail, as internally it will try to animate the text, find that the JFX toolkit was never initialized and incur in a NPE. This is down to internal changes in JavaFX.

Fixing this by manually initializing the platform through Platform.startup(new Runnable() {}) will work locally, but fail in CI, as it can't run in headless mode. Therefore, it seems we need to introduce TestFX to properly support JavaFX testing and headless support.

[oowekyala]

Thanks for investigating this. I'm not sure we can upgrade and also keep compatibility with older versions of JavaFX, because we use some internal JavaFX APIs, or our dependencies might (eg controlsfx).

About testfx, I found this old commit in master, which may be a starting point: d2e45da

[jsotuyod]

The dependencies for javafx have scope provided, are not shipped in the binary, as we rely on the installed JavaFX of the client (OS dependent). The public API has no changes, bumping the version still builds the code as-is (only regression is on the tests as pointed out). The change only has impact during testing / running from the IDE.

Notice that, in practice, users are already using the designer against newer JavaFX versions (ie: I've used 15, 17 and I'm currently using 18 locally).

[adangel]

Firstly, the first test to use CodeArea will fail,

This test has been removed with 0de0b01 , so changing the openjfx version doesn't fail the build anymore (through failing unit tests).

javafx 11 required at least Java 10 (https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-11.md) - the classes are compiled against java 10.

That means, if you use openjfx, you are using anyway at least use java 11 (because java 10 is EOL).

That gives us the option, to update openjfx in general, e.g. up to openjfx 19 still works with Java 11.

I'm going to upgrade openjfx to 17, because that's a LTS version, that seems to be supported for a while (https://gluonhq.com/products/javafx/)

Using the designer built against openjfx 17 still seems to work with Oracle Java 8 with included javafx. Since we don't really build/test against that version, we might see some incompatibilities. But only if someone still really uses (commercial) Java 8.

This upgrade solves the problems with Mac OS X development and makes it easier to develop in general, because you use by default an up-to-date openjfx version with all the bug fixes (e.g. the application icon doesn't work in openjfx 11).