Move to Java 11 ?

[Jugen]

Currently RichTextFX has a minimum requirement of Java 8.

I'd greatly appreciate having community feedback with regards to moving to Java 11. If nobody objects then version 0.10.7 will be the last Java 8 compatible release.

Also what should the new release version based on Java 11 be:

1. Just go with the natural next step: 0.11.0
2. Its been so long now, drop the leading zero: 11.0
3. The library is mature enough to finally have a version one: 1.0.0

[afester]

BTW: The reason for the Gradle upgrade was my plan to add Java 11 support ;-) I already have a local branch which builds and runs on Java 11. Now that the Gradle upgrade works I will continue on that. The major difference is that the JavaFX libraries are not bundled with the JDK anymore so I used the javafx gradle plugin...

[Jugen]

That's great ! Tip: there are four (4) changes that can be done with moving to Java 11:

1. Move java files from "richtextfx/src/main/java9/org/fxmisc/richtext" to "richtextfx/src/main/java/org/fxmisc/richtext" overwriting any existing files, and then deleting the java9 folder.
2. Remove dependency on JavaFXCompatibility, there are only two (2) references in TextExt and ParagraphText each, then delete it and MultiReleaseJarTest under integrationTest.
3. (Optional) Remove gradle testing against jar files, and reverting back to testing against classes.
4. Remove the gradle multi-jar assembly and manifest specification.

[mkpaz]

It's really a good step forward. Though, I believe the worst part about RichTextFX now are its dependencies. Abandoned and not modularized. Switching to Java 11 usually means that lib is fully compatible with Java modules, but until all its dependencies are also modularized it's not true. So, switching to Java 11 you'll lose Java 8 users, but won't make Java 11+ users life better. Imho, dependencies should either included to the RichTextFX codebase (UndoFX) or modularized as it is (the rest of them) first, then switch. In that case it definitely would be 1.0.0 (semantic versioning rules).

[afester]

It's really a good step forward. Though, I believe the worst part about RichTextFX now are its dependencies. Abandoned and not modularized. Switching to Java 11 usually means that lib is fully compatible with Java modules, but until all its dependencies are also modularized it's not true. So, switching to Java 11 you'll lose Java 8 users, but won't make Java 11+ users life better. Imho, dependencies should either included to the RichTextFX codebase (UndoFX) or modularized as it is (the rest of them) first, then switch.

There are several issues with Java 11: The first is that JavaFX is not shipped with the JDK anymore. This needs to be fixed first in order to be able to build RichtextFX on Java 11 at all. Once this works we can work towards modularization - essentially there must not be any modules at all (The JPMS supports non-modularized libraries along with modularized ones), but this is probably what you mean with "won't make Java 11+ users life better".

Also, the question about Java 8 is a good one: Do we really want to drop support for Java versions < 11? I would say "yes", simply to reduce the complexity. Also, Java 8 (the LTS version prior to Java 11) is EOL since 2+ years. Do we have an idea of how many applications which use RichtextFX are still on Java 8 (or 9 / 10)?

[afester]

If you are interested, my work in progress is available at https://github.com/afester/RichTextFX/tree/jdk11 - building the source and running the demos works on JDK 11. This has the adjusted gradle build files, especially the additional "javafx" plugin which pulls the JavaFX jars from the maven repository (since they are not bundled with the JDK anymore). Also I moved the "jdk9" specific sources back to the main source directory. I did not take any care of still supporting some kind of Java 8 / Java 9 build so far - as of now, this will only work on Java 11.

[Jugen]

That's great, thanks :-)

[Col-E]

Do we have an idea of how many applications which use RichtextFX are still on Java 8 (or 9 / 10)?

Me. From my interactions most users are still on 8. But I don't mind forcing an update on my dev3 rewrite branch.

[Col-E]

Actually you can see on github who uses RichTextFX. Github seems to think another repo is the artifact definition: https://github.com/lgu-lab/javafx-richtextfx/network/dependents

[Siedlerchr]

Considering that javafx17 and jdk 17 are both LTS, I think using java 11 would be a minimum now https://gluonhq.com/products/javafx/

[afester]

I have completed most of the Java11 tasks and pushed the code to my personal branch at https://github.com/afester/RichTextFX/tree/jdk11.

• Move java files from "richtextfx/src/main/java9/org/fxmisc/richtext" to "richtextfx/src/main/java/org/fxmisc/richtext" overwriting any existing files, and then deleting the java9 folder. :heavy_check_mark:

• Remove dependency on JavaFXCompatibility, there are only two (2) references in TextExt and ParagraphText each, then delete it and MultiReleaseJarTest under integrationTest. :heavy_check_mark:

• Remove gradle testing against jar files, and reverting back to testing against classes. :heavy_check_mark:

• Remove the gradle multi-jar assembly and manifest specification. :heavy_check_mark:

• Remove the creation of fat jar files. They do not work anymore with Java 11 (especially for JavaFX).:heavy_check_mark:

• Add a jlink task to create a complete execution environment for the Demos (as the replacement for the demo fat jar):x:

I still would like to add the jlink task, and then prepare the branch for a pull request.

[Jugen]

@afester Thanks a stack for this Andreas, I really appreciate it.

With regards to bullet point 5 and fat jar files, I'm using the fat jar without issues with Java 11 and JavaFX. My application is still using the class path though and not modules. What issue have you encountered or seen ?

[Siedlerchr]

For jlink I can recommend the following plugin https://badass-jlink-plugin.beryx.org/releases/latest/

[afester]

With regards to bullet point 5 and fat jar files, I'm using the fat jar without issues with Java 11 and JavaFX.

Interesting - I never got that to work, and my theory was that the JavaFX jar files always need to be on the module path (See also https://bugs.openjdk.java.net/browse/JDK-8256362: "As of JDK 9, the JavaFX runtime expects to be loaded as a set of named javafx.* modules, and no longer supports loading those modules from the classpath"). When I nevertheless tried that, I was getting an error like "JavaFX runtime components are missing, and are required to run this application"

Are you using some special --add-modules parameters?

[afester]

@Siedlerchr Thanks, thats exactly the one I already used in another project and which I plan to use here also :-)

[Col-E]

"JavaFX runtime components are missing, and are required to run this application"

@afester I have never encountered this issue when running a JavaFX fatJar application across varying versions (Java 8, 11, 14, 16). The only message I've ever gotten was:

Oct 26, 2021 6:55:58 AM com.sun.javafx.application.PlatformImpl startup WARNING: Unsupported JavaFX configuration: classes were loaded from 'unnamed module @12edcd21'

Despite the warning the target application runs just fine. I think that at the time of speaking "unsupported" does not mean "it does not work" but rather "we recommend doing it modularly". This is backed up by what Johan Vos says in the thread: https://bugs.openjdk.java.net/browse/JDK-8256362?focusedCommentId=14381344&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14381344

[Jugen]

@afester So when running with JavaFX as a separate library from the JVM, (say in folder jfx) I specify the following parameters:

java -p jfx/lib --add-modules=ALL-MODULE-PATH -jar myApp.jar

or I set the following environment variable:

set JDK_JAVA_OPTIONS=-p jfx/lib --add-modules ALL-MODULE-PATH

and then just run with: java -jar myApp.jar

Nowadays I use JVM's bundled with JavaFX like Azul or BellSoft in which case I just launch without any special parameters or environment variables.

In all cases my application's jar file MANIFEST contains a standard Class-Path entry specifying all the libraries it needs (except for JavaFX which is on the module path).

[afester]

I did some additional investigation with this, and it seems that

java -p jfx/lib --add-modules=ALL-MODULE-PATH -jar ./richtextfx-demos/build/libs/richtextfx-demos-fat-1.0.0-SNAPSHOT.jar

works, provided that

• JavaFX libraries are located in a local directory (like jfx/lib) and are NOT contained in the fat jar itself (which was the case before)
• The local directory is added to the module path with -p
• As of now, possible module-info.class files are filtered out when creating the fat jar (since they would come from different jar file dependencies)
• The jar file contains a Main-Class header in its MANIFEST.MF file - this needs to be a kind of launcher class which allows to specify which demo to run

UPDATE: I have created a launcher class which can be specified as Main-Class in the manifest file, and when using this class to launch the various demos it also works when the javafx libraries are inside the fat jar - for example:

java -jar ./richtextfx-demos/build/libs/richtextfx-demos-fat-1.0.0-SNAPSHOT.jar RichTextDemo

launches the RichTextDemo.

[ghost]

RichTextFX 1.0.0 is fine by me.

[garybentley]

I don't think the issue here is which java version is required, the two main issues (in my mind) are:

1. Post v8 java versions no longer have javafx bundled so there needs to be a way to either specify the module path or the javafx version if the javafx gradle plugin is used. @afester uses the javafx gradle plugin and that seems to work. I tested the changes in their repo and I can build RichTextFX using Java 12 and JavaFX 12.

2. RichTextFX should probably now be a module itself, as should each of its dependencies.

I think moving to v1 is fine now.

[ghost]

Post v8 java versions no longer have javafx bundled

FWIW, BellSoft's Liberica full JDK version bundles JavaFX. The installer script for KeenWrite (my Markdown editor) downloads the "full" JRE version specifically for this reason. See:

https://bell-sw.com/pages/downloads/#/java-17-current

[swpalmer]

In that case it definitely would be 1.0.0 (semantic versioning rules).

For a 0.* release the semantic versioning rules allow anything to break. https://semver.org/#spec-item-4

[dwalluck]

2. RichTextFX should probably now be a module itself, as should each of its dependencies.

I think this means updating both reactfx and wellbehavedfx which aren't modularized. I think flowless and undo are OK, or at least I didn't see any warning about filename-based automodules when building a project with maven.

[mkpaz]

@Jugen Thanks for you great work by keeping the project alive. Still if you don't mind me asking, do you have any plans to continue working on this issue?

[Jugen]

Yes, I intend to publish a release in the next few weeks ....

[Jugen]

RichTextFX 0.11.0 has now been released and is available on maven. The jar has an automatic module name of 'org.fxmisc.richtext' specified in the jar's manifest.