Compatibility for >= Java 9

[mattwright324]

Currently, this software works the best when running it with Java 8.

There are some visual changes when using Java 9 or 10 with regards to JavaFX application scaling but should work the same for the most part.

With Java 9, the module system is introduced. This has some issues regarding dependencies and whether they have been made modular. Meaning, while the application can be ran in 9 and 10, it can't be built against 9 or 10 yet.

With Java 11, they remove JavaFX completely and it must be included as additional jars bundled as libraries with the application.

Currently the module system is the only thing holding back upgrading and building against Java 11, their current LTS version.

[mattwright324]

Currently experimenting with gradle and packaging YCS with a custom JDK 16 runtime in branch gradle-jdk16. Downside is that download size goes up from 15-16 MB (current) to 78 MB (zipped) / 133 MB (unzipped). This is as small as I can get it when using the beryx runtime plugin to only include necessary JDK features.

Branch gradle-jdk16

Good stuff

• Development
  • Get to use new JDK features
  • Beryx Runtime plugin fixes module problems
• User
  • Doesn't need to install Java 8
  • Doesn't care what JDK version is installed on system or lack thereof

Concerns

• Larger download size
• Releases
  • Platform specific ?
  • Installers ?

[bernard01]

Hi,
Some time ago I experimented with a simple OpenJFX project and Maven. I thought that it should be possible to create a baseline simplistic Hello World type of project with a working deployment pipeline. Got into trouble. See:
moditect/moditect#114
Then I read that it is not even possible fundamentally to achieve some of it:
https://www.sitepoint.com/maven-cannot-generate-module-declaration/

I feel Java desktop application development (at least) is in SERIOUS trouble on Java 9+ for reasons OTHER than the the problems that Java desktop has e.g. cross platform differences. A build system such as Maven is pivotal. It can bring down entire language if it fails to deliver. It is the preferred build system in the NetBeans IDE. Now I see you switch to Gradle. Perhaps for the same reasons I found? It looks as if we need to switch to Gradle to survive? What am I missing?

[mattwright324]

Well, I chose Gradle in that experiment because I've used it at work and found that to bundle a custom runtime, the Gradle Beryx Runtime plugin that does that seemed easier than whatever I came across for Maven.

The module system is another complication. Also included in the Beryx Runtime plugin is an additive setting which does what you were looking for when packaging the application.

In many cases, the list of modules provided by the suggestModules task contains exactly the modules required by your application. This means that you don’t need to configure the modules property, because the plugin can figure out by itself which modules are required. In some other cases, the "suggested" list of modules is almost right, in the sense that it only misses one or a few modules. In these cases, you are allowed to specify only the missing modules in the modules property, and you instruct the plugin to add them to the list of suggested modules, by setting the property additive to true.

I have not used slf4j before but I would recommend trying log4j2.

However, I am also now experimenting with Electron as a possible alternative though I am completely new to that whole ecosystem and it could take some time to learn it. Depends how performant an equivalent refresh process in web worker threads compares to my Java implementation.