javafx-gradle-plugin
javafx-gradle-plugin copied to clipboard
FibreFoX
Java 10+ support
When I try to build with Java 10, the plugin (version 8.8.2) fails with Couldn't find Ant-JavaFX-library, please make sure you've installed some JDK which includes JavaFX (e.g. OracleJDK or OpenJDK and OpenJFX), and JAVA_HOME is set properly.
There's a test in JavaFXGradlePlugin.java (lines 100-105) for Java 9, which of course fails (since the version is 10), so it falls backs to the Java 8 path instead.
I believe it would be better to skip the version test entirely and just if the Ant-JavaFX-library exists in either "lib" or "../lib", whichever works.
You might want to check if this works with the SNAPSHOT-version, see this for more information: https://github.com/FibreFoX/javafx-gradle-plugin/issues/57#issuecomment-359281615
As the JDK 10 is not yet official/stable, there is no support for this yet. (And a personal note: rapid-releasement of the JDK is a real pain IMHO)
Sorry; didn't work either. Same error.
Snippet from build log:
Current JVM is 10 ("Oracle Corporation" 10+43), adding '--add-modules java.xml.bind' to javadoc options
Download https://oss.sonatype.org/content/repositories/snapshots/de/dynamicfiles/projects/gradle/plugins/javafx-gradle-plugin/8.9.0-SNAPSHOT/maven-metadata.xml
Download https://oss.sonatype.org/content/repositories/snapshots/de/dynamicfiles/projects/gradle/plugins/javafx-gradle-plugin/8.9.0-SNAPSHOT/javafx-gradle-plugin-8.9.0-20180121.194453-2.pom
Download http://nexus.cinnober.com/nexus/content/groups/public/org/ow2/asm/asm-all/5.1/asm-all-5.1.pom
Download http://nexus.cinnober.com/nexus/content/groups/public/org/ow2/asm/asm-parent/5.1/asm-parent-5.1.pom
Download http://nexus.cinnober.com/nexus/content/groups/public/org/ow2/ow2/1.3/ow2-1.3.pom
Download http://nexus.cinnober.com/nexus/content/groups/public/org/ow2/asm/asm-all/5.1/asm-all-5.1.jar
Download https://oss.sonatype.org/content/repositories/snapshots/de/dynamicfiles/projects/gradle/plugins/javafx-gradle-plugin/8.9.0-SNAPSHOT/javafx-gradle-plugin-8.9.0-20180121.194453-2.jar
> Configure project :GUI
base=:Base, gui=:GUI
Current JVM is 10 ("Oracle Corporation" 10+43), adding '--add-modules java.xml.bind' to jfx options
Current JVM is 10 ("Oracle Corporation" 10+43), adding '--add-modules java.xml.bind' to javadoc options
Current JVM is 10 ("Oracle Corporation" 10+43), adding '--add-modules java.xml.bind' to run options
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':GUI'.
> Couldn't find Ant-JavaFX-library, please make sure you've installed some JDK which includes JavaFX (e.g. OracleJDK or OpenJDK and OpenJFX), and JAVA_HOME is set properly.
Yet ant-javafx.jar really is there:
$ ls -l $JAVA_HOME/lib/ant-javafx.jar
-rw-r--r-- 1 root wheel 158490 8 Feb 04:17 /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/lib/ant-javafx.jar
Yes, it is existing, but does not contain the same stuff ;) will look into this the next days.
Hi, first of all thanks for the work you put into the plugin.
I just tried the current snapshot version of the plugin with JDK 10 EA. Gradle dies with this exception (shortened the stacktrace to the relevant bit of information):
Caused by: org.gradle.api.GradleException: Couldn't find Ant-JavaFX-library, please make sure you've installed some JDK which includes JavaFX (e.g. OracleJDK or OpenJDK and OpenJFX), and JAVA_HOME is set properly.
at de.dynamicfiles.projects.gradle.plugins.javafx.JavaFXGradlePlugin.addJavaFXAntJARToGradleBuildpath(JavaFXGradlePlugin.java:112)
This is the code of JavaFXGradlePlugin.java that I just pulled from Github:
private void addJavaFXAntJARToGradleBuildpath(Project project) {
String jfxAntJarPath = "/../lib/" + ANT_JAVAFX_JAR_FILENAME;
// on java 9, we have a different path
if( JavaDetectionTools.IS_JAVA_9 ){
jfxAntJarPath = "/lib/" + ANT_JAVAFX_JAR_FILENAME;
}
// always use ant-javafx.jar from the executing JDK (do not use environment-specific paths)
// per spec "java.home" points to the JRE: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
File jfxAntJar = new File(System.getProperty("java.home") + jfxAntJarPath);
if( !jfxAntJar.exists() ){
throw new GradleException("Couldn't find Ant-JavaFX-library, please make sure you've installed some JDK which includes JavaFX (e.g. OracleJDK or OpenJDK and OpenJFX), and JAVA_HOME is set properly.");
}
So there's a special case for Java 9 and above, where ant-javafx.jar is assumed to be at another place. I have several JDKs lieing around on my machine, and when I look for the jar, I get this:
$ find . -name ant-javafx.jar
./jdk-10/lib/ant-javafx.jar
./jdk-9/lib/ant-javafx.jar
./jdk1.8.0_131/lib/ant-javafx.jar
./jdk1.8.0_162/lib/ant-javafx.jar
It seems no special case should be necessary for JDK 9 and above. You said "Yes, it is existing, but does not contain the same stuff ;)". But I think that would then be another issue since the exception we see is clearly just because of the jar not being where it's supposed to be.
Maybe it's worth just trying to comment out lines 101-105 and see what happens?
It's not that ant-javafx.jar is in another place; it is java.home which is different, or really, the packaging of the JDK/JRE which is different in Java 9 and later.
Before Java 9, java.home points to <JDK-installation-dir>/jre, In Java 9 and later to <JDK-installation-dir>.
The problem is rather the check for Java 9, which fails on Java 10, making the code try the Java 8 path (../jre) instead. It would perhaps be better to just check both locations and use the one that's found.
Hm... maybe JavaDetectionTools should use Runtime.version() which will report major and minor versions instead. But that was only added in JDK 9, so the call would have to be done using reflection to have something working from JDK 8 upwards.
Despite of PR #112 I will try to work on this issue again tonight, just some planing going aroung before I have time for my projects again. Sorry for the delay.
OK. Just an update on my progress: My primary goal is to be able to build and deploy my application with Java 11. (I believe we should go directIy to Java 11, which hopefully will prove to be a more stable base than 9 and 10.) I can currently build my application with some local patches to gradle and the javafx plugin, but I still need to build them both with java 1.8. Today, I saw that there's has been support for Java 11 committed to gradle, so I hope that from tomorrow morning it should be possible to use a nightly gradle build with Java 11. But I'm struggling to understand how the javapackager is supposed to be used programatically in Java 11. Do you know?
I have no idea if "javapackager" will be available with JDK 11 😿 But I now got two days in a row where I could spend a small amount of time to this project again :) so I will find it out.
It's still there in the EA builds, so I can build my application with Java 11. Building the plugin with JDK 11 fails on the de.dynamicfiles.projects.gradle.plugins.javafx.tasks.workarounds.MacAppBundlerWithAdditionalResources, since it uses some com.oracle.tools.packager.* classes which are hidden in JDK 11.
FYI, I don't need the workaround (I have no extra bundle resources), so when I build the plugin with JDK 8, 9, or 10 (with my PR #112 and #113 in place), and then build my application with JDK 11, it gets packaged OK with JDK 11 on my Mac. I guess it would fail if I had needed the workaround.
I have tried to look into compiling with the freshly released JDK 10. I changed build.gradle to make the mentioned packages accessible. The classes are still there,but they changed in a way that it still doesn't compile (like methods that used to be public are now private and thus cannot be overridden).
I am still relatively new to using this plugin and don't know yet how important the extra functionality provided by MacAppBundlerWithAdditionalResources is. If it is important, there should be a way to implement it using only the official API so that it won't break again.
There is already a working-branch: https://github.com/FibreFoX/javafx-gradle-plugin/tree/newyear2018release
I understand the pressure of the community to have a nice way for using the javapackager through this plugin. It personally influences me already for not having a working solution, but the whole thing is very complex, in addition to the new jigsaw shenanigans. Please bear with me some more days, already working on a solution to have this fixed without some restrictions to the JDK. As JDK 11 is going to drop JavaFX from the bundled JDK, this will get more complicated too.
Hi, I just stumbled upon this issue when attempting to run a Griffon application on top of JDK 10. I modified the plugin with a "simple" fix, basically inverting IS_JAVA_8 instead of checking for Java9 or newer.
@aalmiray That crossed my mind too, I added some of that stuff while JDK was not-yet-released and not-yet-jigsawed. I'm already planing some evil stuff and are hoping to provide something next week, but might bring some developers at rage. Will report as soon as I can.
Ehm... just one thought... don't know if this is the right place to ask, but...
There seem to be some problems caused by interpreting the Java version String in JavaDetectionTools.java. But since this plugin depends on org.gradle.api anyway, wouldn't it be much simpler to simply call org.gradle.apiJavaVersion.current().isJava9Compatible(), which is available at lest since version 2.14 of gradle? I think JavaDetectionTools could then be dumped altogether.
@xzel23 For some workarounds I need to check against not only JDK8 vs JDK9 but for update-version too. I'm already on some experimental (non public) work to address such issues.
You need the latest gradle nightly build (since yesterday) to run gradle with Java 11.
JDK 11 broke some other parts, and as the future of JavaFX is separated from Oracle-provided JDKs, and the javapackager (and other resources) sitting inside that JDK prior JDK11, makes it nearly impossible for supporting this any further.
Some of my twitter-followers might have already seen this, and maybe some other github-users (some are watching me too), I'm working on a replacement of the javafx-gradle-plugin and will provide some nice transition-instructions.
Please don't ask for any ETA, but it's more than clear now, that instead of fighting against moving targets, my vision is to avoid having dependencies in that kind the javafx-gradle-plugin actually is.
In case anybody is interested, I started my own JPMS-plugin to help building modularised libraries with gradle. In the meantime, I added a jlink task and succeeded to build some standalone (= no JRE installation required) JavaFX applications with it. The drawback is of course that all dependencies also have to be modularised too, and it cannot create installers etc.
If you find it useful, or something doesn't work as expected, or it contains something you'd like to integrate into the successor of your plugin, please let me know.
@xzel23 normally I do not like adverizement for other plugins ;) and the functionality of this gradle-plugin is still available, on JDK > 8 it's creatable by calling the javapackager via process execution.
But to state this here, maybe it wasn't that clear: the next plugin superseeds this one, means all functionality, including jlink, installers, native launchers, will be present .... for the time being it will even use the resources bundled from the JavaFX-parts.
Please note that javapackager is gone from JDK 11 with no replacement. There are plans for a new packager with, hopefully, equivalent functionality, but until that one has arrived (JDK 12?) we really can't hope to move forward.
@lenborje thats the reason why I started to work on a different project, but personal life drains a lot of time currently :(
All work done with JavaFX and the java(fx)packager will get dropped without replacement, its a real nightmare. First JDK9 broke a lot of things (they even refactored stuff, just to throw it away again), than it will get kicked out with JDK11.
Yes, I am aware of your pain, yes, I am aware of this stopping you from using this, and I really am sorry ... and no, I still plan to have my other project up&running before JDK11 hits the GA-release. :(
FWIW there's a thread at the OpenJDK mailing list discussing if javafxpackager should be moved to core, thus remaining available to everybody without an additional download, probably renamed (back) to javapackager or jpackager.
If that's not the case, then javafxpackager remains available as a separate download. JavaFX will be moved to its own, separate module in JDK11 (oracleJDK) which is no different with what OpenJDK users have been accustomed to since JavaFX was open source under the OpenJFX project (around OpenJDK7). Let me repeat, the change only affects OracleJDK 11 going forward, and given Oracle's recent announcement that you must pay a license for using OracleJDK in production ... there will be fewer installations of OracleJDK 11 in the wild and more OpenJDK.
Donald Smith blogged at https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates while the official white-paper is available at http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
Lastly, the proposed JEP to keep javapacker inside core OpenJDK is http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html https://bugs.openjdk.java.net/browse/JDK-8200758
When my JRE was last updated on my Mac, I got a pop-up directing me to https://java.com/en/download/release_notice.jsp, which summarises Oracle's announcement and provides links to references. We're currently replacing all use of Oracle JDKs with OpenJDK.
As of Java 11 the javapackager is removed. Also Java Web Start has also been removed as of Java 11.
There is a new jpackager targeted for Java 12. Johan Vos at Gluon has backported the jpackager into OpenJDK 11, and made available this tool. Perhaps if this plugin could switch to that tool instead.
As promised, we looked into an interim solution for the packager-gap. Work for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. We backported the required changes to an OpenJDK 11 mirror: https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager (wrapper/exe + module including native library). They can be downloaded and tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK, as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create installers (e.g. we're using them for Scene Builder 11 and that works fine), and they do what we expect them to do, but there are no guarantees of course so at least for now I recommend using them in development only (or even better, look at the changes and contribute to https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
