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. ✔️

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

• Remove gradle testing against jar files, and reverting back to testing against classes. ✔️

• Remove the gradle multi-jar assembly and manifest specification. ✔️

• 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/