You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 Siqueira
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
Support for JavaFX has been added with #27 being merged in. Big thanks to @giltene ! 🎉
README.md has been updated to reflect the recent changes. As long as you're using actions/setup-java@v1 then you should be able to use the most recent changes
Reacted by Madhuri Gummalla, airsquared, Mark Snijder and autumo
Activity
airsquared commentedon Aug 27, 2019
@damccorm Would this be possible?
damccorm commentedon Aug 28, 2019
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.
airsquared commentedon Aug 29, 2019
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:
setup-java/src/installer.ts
Line 200 in 91b87ac
would be changed to
let versions = ref.match(/ca-fx-jdk.*-/gi) || [];.airsquared commentedon Aug 31, 2019
@damccorm, @stephenmichaelf I created a PR: #19.
Siedlerchr commentedon Sep 13, 2019
Alternatively one could use the Liberica JDK which already inlcudes javafx:
https://bell-sw.com/pages/java-11.0.4/
giltene commentedon Sep 27, 2019
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.
msgilligan commentedon Oct 1, 2019
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:
giltene commentedon Oct 1, 2019
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.
msgilligan commentedon Oct 1, 2019
Thanks @giltene for the detailed explanation. Totally makes sense.
giltene commentedon Nov 3, 2019
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
konradpabjan commentedon Nov 22, 2019
Support for JavaFX has been added with #27 being merged in. Big thanks to @giltene ! 🎉
README.mdhas been updated to reflect the recent changes. As long as you're usingactions/setup-java@v1then you should be able to use the most recent changesPossible fix for missing JFX
Fix for missing JFX with GitHub Actions (#793)