Add support for JPMS / Java 11 / module system

[dlemmermann]

For jlink / jpackage support it would be great if a Java 11 version could be made available.

[dustinkredmond]

@dlemmermann This has been a big to-do of mine. I have not yet had the time, but plan to do this in the future. I would love some help from someone with experience in Java 9+ also. I have not had the time to dedicate learning the ins and outs of JPMS quite yet.

[dwalluck]

Creating a module-info.java file is not so difficult, but retaining support for Java 8 while supporting Java 9+ is even more complicated because it requires a multi-release jar build.

I think that creating a native runtime image would still not be possible because AWT is not supported unless there is some way to support the system tray without AWT.

[dlemmermann]

In my projects I usually have two branches. One for Java 8, one for 9+. Multi-release JARs have caused me a lot of headache in the past as the are hard to detect and maven / gradle builds can easily get confused. I would definitely go with two separate releases.

[dwalluck]

I basically agree. For my "enterprise" projects, I am still "stuck" on Java 8, and for my "personal" projects, it was just easier to move to Java 11.

Besides, for jfx projects, I don't see much point in keeping Java 8 support since having proper module support is really more important.

[dustinkredmond]

@dwalluck, Exactly, it's trying to support multiple releases that makes this difficult. For new JavaFX projects, I go straight for the latest JDK/version of JavaFX.

From the e-mails that I get (on an almost daily basis) I really hate not to support Java 8. It's very surprising how many folks are constrained to using JDK 8, or even earlier JDK versions. I would have guessed that most JavaFX projects would have migrated to a more recent JDK, but, unfortunately, that's not been priority for a lot of folks.

That being said, when we do provide support for JPMS, I will almost certainly have different branches and Maven artifacts for JDK 8 and JDKs 9+. I really wish there was a cleaner way to do this, but given the current state of the Java ecosystem, I think it's something we'll have to live with.

[EasyG0ing1]

@dustinkredmond - I've gotten VERY comfortable with modularized Java ... I've been using Java 17 for everything for the last couple of months. I could easily port FXTrayIcon to be JPMS friendly ... and I do agree that keeping two separate projects is the way to do this, and FXTrayIcon isn't so large of a library ... it wouldn't be difficult to maintain two versions of the project. I mean when you really look at it ... it's a powerful library, but also very simple in terms of the amount of code it has.

[dustinkredmond]

I'm down for doing this. As a library, this will not be a major change. Since there's no buildable artefacts, this change poses no major disruptments to our users. I will keep this issue open until the release is pushed.

[EasyG0ing1]

@dustinkredmond - So it turns out that I don't think we are going to need to have two different projects here. I've been reading up on some methods that will build a jar file that is compatible with both modular and non-modular projects and also compatible with 1.8 and back as well as 9 and forward using some POM file magic and a couple of plugins ... I wanna test this out once I dive in a little deeper.

[dustinkredmond]

Closing for now, too many folks still on JVM 8, and too many projects now using the library. Plans to do a separate branch/release in future to support older as well as newer JDKs.

[ctoabidmaqbool]

For jdk 8 and Jdk 11 separate codding, I think separate branches are enough.

For automatic release cycle, you can setup GitHub Actions, which automatically runs while commenting codding.