Codename One itself never depended on JavaFX. This kept us small and performant. However, we need JavaFX to support HTML and media in the simulator and on the desktop ports. This was a choice we made easily back in the Java 8 days. JavaFX was integrated into the official JDK and this was an easy choice to make.
Then Java 9 came out and everything broke. Most JVMs ship without JavaFX now and downloading it dynamically for the simulator is error prone to say the least. Even I had problems setting up our environment on some foreign machines. Every day we need to deal with multiple support queries and people who have issues with VM configuration. 99% are due to the pain of dealing with JavaFX installation on top of the VM.
Not Worth Fixing
There are many approaches we could take to try and solve this. All of them suck but they are possible…
We could create different versions of Codename One for each platform and ship with our own OpenJDK port that includes everything we need. This would have ballooned the size of install and made it harder for you to customize/tinker with Codename One.
The problem is we’d still be stuck with FX.
The main reason for using FX is the
BrowserComponent. Swing just doesn’t have a decent browser widget and FX provides the closest thing to a browser we can use…
The thing is, it still sucks. Newer web standards aren’t supported. Debugging is difficult and it crashes… A lot.
A Better Way
If we migrate to JCEF we’d have access to the latest Chromium APIs and tools. Ideally we’d also enjoy better stability, control and JVM compatibility. The drawback is that we’d need to write native code and possibly increase the Codename One download size.
The big missing piece here is media. We’re still testing the waters on this but a good direction might be to use the media capabilities of Chromium to show things in the simulator and desktop ports.
In order to maintain compatibility for developers using the desktop port we’ll keep the existing implementation that relies on JavaFX for the short term. Since the desktop port packages the VM within this shouldn’t be a problem.
However, we will change the default build to use JCEF once we deem this stable enough and might eventually sunset the FX port entirely based on your feedback. This will have a big size advantage for developers as we’ll be able to package a smaller VM without the JavaFX dependency.