Repository navigation
Add support for JavaFX builds #18
Description
Activity
@damccorm Would this be possible?
I think I'm going to defer to @stephenmichaelf on this one. I could really go either way on whether or not this belongs in this action or a separate setup action (e.g. setup-javafx).
It feels kinda similar to actions/setup-ruby#20, but its not quite the same in that JavaFX is a superset of Java and not just a straight up implementation (like in the Ruby example). If we decide to do this, we should align syntax across both actions though.
I don't think there should a separate action for this, as it's just a regular JDK that also includes JavaFX.
I think to add this feature, if the user wants the JavaFX version this line:
Line 200 in 91b87ac
would be changed to
let versions = ref.match(/ca-fx-jdk.*-/gi) || [];.@damccorm, @stephenmichaelf I created a PR: #19.
Alternatively one could use the Liberica JDK which already inlcudes javafx:
https://bell-sw.com/pages/java-11.0.4/Zulu Community has been making fx-bundled variants (...fx-jdkX.Y.Z... vs. ...jdkX.Y.Z...) available starting with 8 and 11 versions 8u202 and 11.0.3, and will continue to provide fx variants for all future updates of those LTS versions. So I can confirm that the parsing suggested in the referenced pull request will continue to work reliably.
And, of course, you can now download JavaFX via maven/gradle since it has been decoupled from the JDK. That's how I've been happily doing it recently.
See:
The main driver for us building and providing FX-bundled versions of Zulu JDKs was making sure things work well in transitioning from Oracle JDK 8 to OpenJDK 8. Since Oracle JDK 8 had JavaFX bundled, none of the gradle/maven tooling stuff (as much as I personally use them. recommend them, and am happy/thankful for the community effort put into them) provides a "drop in", zero changes means for replacing the Oracle JDK. Bundling is there becuase many people's existing code and workflows assume FX-bundling.
Ironically, one of the most common drivers for people looking for a JavaFX-bundled JDK is not actual JavaFX application use, but "accidental"/unintentional use of some useful classes that happened to be part of JavaFX, but not part of the JDK, and were historically bundled in Oracle JDK 8.
E.g. one of the most popular transitioning problem we've run into with plain OpenJDK 8 JDK is that is that OpenJDK 8 is "missing" javafx.util.Pair<K,V>. And yes, it's just a Pair class, and there are 342 other places you can get a good Pair class from. But that pair class was "part" of Oracle JDK 8, and it just worked there, and it is already in many people's code, so...
This then continues with OpenJDK 11, where people transitioning existing code from 8 to 11 run into these "missing" FX classes (on top of all their other post-Java-8 trasitioning pain). We've run into enough of that in the real world that we chose to regularly provide FX-bundled OpenJDK 11 with Zulu starting with 11.0.3.
Reacted by Sean Gilligan, David Phillips, Sergei Grinev, Curtis Rueden and Adriano SiqueiraThanks @giltene for the detailed explanation. Totally makes sense.
I've created a separate pull request #27 that covers the requested feature but with a different syntax than the one proposed here: The change introduces a new java-package option that supports jre, jdk, and jdk+fx as accepted values (defaults to jdk and retains current behavior unless jre or jdk+fx is specified). I believe that this syntax (a single option to cover current and possible future package types) is preferable to having individual booleans per package type.
The action is available for testing as foo-actions/setup-java@master
- Reacted by Madhuri Gummalla, airsquared, Mark Snijder and autumo
- added a commit that references this issue
on Jan 22, 2021
Something like
I believe Zulu just has
ca-fxin the name of jdk versions with JavaFX.