Re: Filling the Packager gap
On 9/19/18 3:55 AM, Johan Vos wrote: Hi, 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) - Johan The JDK source fails to compile due to a duplicate qualified export. Removing the export from openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java fixes it. By the way, how does one use this with jLink generated by Netbeans? I used the jLink build as the input and it just dumped it into the "app" folder when making the image which doesn't work.
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
> > but wouldn't go out of our way to stop it from running on JDK N-2 > unless/until there was a feature or bug fix that required something from > JDK N-1. > I would be surprised if there will be a release without a language change, as I don't recall any release without one, and Amber (and friends) keeps providing. Now, we can discuss what is "required". Java 11 added 'var' for Lambdas. Is it something worth bumping the minimum version for? Isn't it enough that it's used once in the codebase to make it incompatible with pre-11 JDK's? And if so, we'll have to document what contributors are allowed to use and what not when working on JavaFX. We will have to have this discussion every release to determine if we bump the minimum version or not. On Thu, Sep 27, 2018 at 12:27 AM José J. Rodriguez < jose.rodrig...@cenpalab.cu> wrote: > Ty Young wrote: > > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) release > > for building JavaFX? I feel like maybe that would be more reasonable. > > > > > FWIW, I would prefer it if jfx only followed the LTS jdk releases. > > Regards, > Joe1962 >
Re: Filling the Packager gap
No, jlink won't link in a non-modular application. So the steps are: 1) Run jlink to create a Java runtime image, possibly stripped down, and include the javafx.* modules you need 2) Run jpackager to package your non-modular application with the above Java runtime image. -- Kevin On 9/26/2018 3:23 PM, Scott Palmer wrote: Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can’t automatically figure out module dependencies. The error below shows jlink is what is complaining. Scott On Sep 26, 2018, at 3:44 PM, Kevin Rushforth wrote: jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds). Andy might have additional comments. -- Kevin On 9/26/2018 11:50 AM, Sverre Moe wrote: I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11). I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : Hi, 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
Re: Filling the Packager gap
Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can’t automatically figure out module dependencies. The error below shows jlink is what is complaining. Scott > On Sep 26, 2018, at 3:44 PM, Kevin Rushforth > wrote: > > jpackager should work for non-modular applications as well as modular ones. > We've tested it for simple applications with or without FX. In the latter > case, the testing I've done has been done by first using jlink to create a > Java runtime with the needed JDK modules + the openjfx11 modules (using the > jomds). > > Andy might have additional comments. > > -- Kevin > > > On 9/26/2018 11:50 AM, Sverre Moe wrote: >> I have tried this jpackager a bit. It is working fine packaging a Java >> modular project. >> However it fails to package a none modular project. I modified my project >> and removed the modularization and tried again to see if it would work to >> package our legacy Java 8 project (though now built with JDK 11 and with >> dependencies on openjfx 11). >> >> I was under the impression that the jpackager should also work to package >> non-modular projects. >> >> The Gradle distribution task produces an tar archive with all the >> dependencies and my own JAR, which I am using as input to the jpackager. >> >> This produces the RPM for the modular project: >> sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> >> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir >> --verbose --echo-mode --module-path . --module >> no.smeaworks.movies/no.smeaworks.movies.MoviesApplication >> >> Using the jpackager to package non modular project: >> sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> >> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib >> --output >> outputDir --verbose --echo-mode --class >> no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar >> >> >> ECHO-MODE: Running [rpmbuild, --version] >> >> "Adding modules: [] to runtime image." >> >> ECHO-MODE: Running jlink [ >> --output = >> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >> --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] >> --add-modules = [] >> --limit-modules = [] >> --exclude-files = .*\.diz >> --strip-native-commands = false >> ] >> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >> Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: >> jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing >> for java.base module >> Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use >> them to customize package. >> Exception in thread "main" jdk.packager.internal.PackagerException: Error: >> Bundler "RPM Bundle" (rpm) failed to produce a bundle. >>at >> jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) >> >>at >> jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) >> >>at jdk.packager/jdk.packager.Main.run(Main.java:71) >>at jdk.packager/jdk.packager.Main.main(Main.java:47) >> >> >> Is my presumption wrong that it should package also non modular projects, >> or am I missing some runtime flags to jpackager? >> >> Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I >> reckon that Gluon has yet to modularize SceneBuilder? Can you provide some >> insight how you use jpackage to build the project? I could not find >> anything on it in the Gluon SceneBuilder GitHub repository. >> >> /Sverre >> >> Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : >> >>> Hi, >>> >>> 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 >>>
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
Ty Young wrote: And it's only going to get worse as time goes on. Would it not be possible to support up until the last JDK LTS(Starting at 11) release for building JavaFX? I feel like maybe that would be more reasonable. FWIW, I would prefer it if jfx only followed the LTS jdk releases. Regards, Joe1962
Re: Filling the Packager gap
jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds). Andy might have additional comments. -- Kevin On 9/26/2018 11:50 AM, Sverre Moe wrote: I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11). I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : Hi, 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) - Johan
Re: Filling the Packager gap
I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11). I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > Hi, > > 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) > > - Johan >
HTTPS download location or checksum available?
Is it possible to change the following page either to download the files over HTTPS or provide their checksums on an HTTPS page (as Oracle does for the JDK)? JavaFX - Gluon https://gluonhq.com/products/javafx/ The page redirects to an insecure HTTP connection when downloading the Linux files, for example: JavaFX Linux SDK http://gluonhq.com/download/javafx-11-sdk-linux/ --> Location: https://gluonhq.com/download/javafx-11-sdk-linux/ --> Location: http://download2.gluonhq.com/openjfx/11/openjfx-11_linux-x64_bin-sdk.zip JavaFX Linux jmods https://gluonhq.com/download/javafx-11-jmods-linux/ --> Location: http://download2.gluonhq.com/openjfx/11/openjfx-11_linux-x64_bin-jmods.zip Is that the official download page outside of the Maven repositories? Thank you, John
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
So I think we should official define the JDK N-1 and JDK N but don't pro actively break JDK N-2, ... if there's no real value. Perhaps your suggestion is a good compromise: if we choose this approach, then we would still claim support for only JDK N-1 and JDK N, but wouldn't go out of our way to stop it from running on JDK N-2 unless/until there was a feature or bug fix that required something from JDK N-1. Given that it could break -- either because we need something from JDK N-2 or because of a bug that gets introduced and we no longer test with JDK N-2 -- application vendors wouldn't be able to rely on FX N working with JDK N-2. Johan: what do you think? -- Kevin On 9/24/2018 12:14 PM, Tom Schindl wrote: Hi, As a general rule I'm fine with that but as outlined in another reply we should only break building with older JDKs in case it really adds value. So I think we should official define the JDK N-1 and JDK N but don't pro actively break JDK N-2, ... if there's no real value. Tom On 24.09.18 16:40, Kevin Rushforth wrote: In general, I think developers updating from JavaFX 11-12-13 are also capable of updating the JDK from 11-12-13, so I prefer the coupling 1. Allow building JavaFX N with either JDK N-1 or JDK N. This is also my preference. -- Kevin On 9/24/2018 12:12 AM, Johan Vos wrote: > And it's only going to get worse as time goes on. Would it not be > possible to support up until the last JDK LTS(Starting at 11) release > for building JavaFX? I feel like maybe that would be more reasonable. This is a good question, and maybe in the future we might not be so quick to do this...or maybe we will. We should discuss this before we get to this point for JavaFX 13, a little less than six months from now. The choices for the model are: 1. Allow building JavaFX N with either JDK N-1 or JDK N. 2. Allow building JavaFX N with the most recent LTS or later. Choice #1 will allow JavaFX to better keep pace with JDK features (API or language features). Choice #2 will allow JavaFX to build and run with the most current, stable JDK LTS at the cost of not being able to use newer JDK features. One of the reasons Java is moving to a fast release cadence is because today, this is required to stay relevant in a fast-changing landscape. I think we need to do the same with JavaFX. We should be able to leverage the latest and greatest advances in the JDK, since this will allow JavaFX to move fast as well, which is required to stay relevant. If you want to run on the latest stable JDK LTS, the logical consequence seems to me you use the latest stable JavaFX LTS. There is LTS support available for both Java and JavaFX 11 and they are pretty well aligned. Having said that, there is no point in moving forward just for the fun of it. We also have to distinguish between changes in the VM or in the core Java API's. My opinion is that if a new feature is added to JDK N, we can really take advantage of it in JavaFX (N+1). In some cases, there won't be new features relevant to OpenJFX. But even then, I don't think we can't change our rules on a per-release case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). In general, I think developers updating from JavaFX 11-12-13 are also capable of updating the JDK from 11-12-13, so I prefer the coupling 1. Allow building JavaFX N with either JDK N-1 or JDK N. - Johan
"Toolkit already initialized" error with OpenJDK 11
Hello Kevin, I already use Platform.setImplicitExit(false) at startup so this can't be the problem. All SWT FXCanvas are not closed (at least at startup). Could it be that the initialisation of the SWT FXCanvas is different and could cause the problem. At the moment I use as java arguments: --module-path C:\javafx-sdk-11\lib --add-modules javafx.controls,javafx.swing,javafx.swt The javafx.swt module is accepted but I have to add the javafx-swt.jar to my classpath to get at least an embedded canvas working. Without the *.jar it won't work at all. Is there a better or recommended option to include the javafx-swt.jar classes at startup in the --add-modules option? The --add-modules javafx.swt doesn't seem to work.
Re: "Toolkit already initialized" error with OpenJDK 11
I'm' not aware of anything that intentionally changed between FX in JDK 8 and FX 11, but my guess is that the FX runtime is being shutdown after your first FXCanvas exits. Try making the following call (only needed one time) before creating your first FXCanvas: Platform.setImplicitExit(false); -- Kevin On 9/26/2018 4:22 AM, marcel Austenfeld wrote: First of all congratulation to the new release and thank you for the hard work on JavaFX. I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse. I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app. This works fine in Java 8 which my current release depends on. However in Java 11 after the second panel is initialized at startup I get the following error: "Caused by: java.lang.IllegalStateException: Toolkit already initialized" Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application? Or do you now any changes since Java 8 which could the cause of such an exception? Thanks in advance for any help.
"Toolkit already initialized" error with OpenJDK 11
First of all congratulation to the new release and thank you for the hard work on JavaFX. I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse. I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app. This works fine in Java 8 which my current release depends on. However in Java 11 after the second panel is initialized at startup I get the following error: "Caused by: java.lang.IllegalStateException: Toolkit already initialized" Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application? Or do you now any changes since Java 8 which could the cause of such an exception? Thanks in advance for any help.
"Toolkit already initialized" error with OpenJDK 11
Re: BUG: zip file in sdk lib folder causes bugged JDK build
On 9/22/18 9:01 AM, Kevin Rushforth wrote: I have never seen this problem. As for including src.zip in the "lib" directory, that matches what the JDK has done for years. It may have something to do with how you are building your JDK? No, I compile JavaFX the same everytime - remove -Werror from the Linux gradle file and ignore all web tests via -x :web:test. Maybe something was changed on the JDK side of things(an exclude list maybe)? I don't remember having this issue before either compiling the pre-release versions of JDK11 and JavaFX either. I used both the JDK11 and JavaFX 11 release branch for the source code. In any case, as mentioned in a previous email, I do not recommend using a boot JDK with JavaFX modules to build FX. This is no longer the expected way to build FX and will quite likely stop working at some point. -- Kevin Why exactly does having the modules in the JDK matter? Worse case scenario they just aren't used, right? Even if it isn't the "expected" way to build JavaFX, it still has advantages over using the standalone SDK and IMO should still be supported. I'm having a hard time understanding why people at Oracle(or Oracle itself) seems to just want to drop features/tools/options and replace them with completely inferior, incomplete, or not as good replacements, like jLink(though the reduced file size is useful). You all must realize that by doing this that you are breaking projects that utilized these features/tools/options(like JPackager) and increasing the amount of work for IDE developers as they have to support whatever feature that is supported on JDK release X but not on release Y(they have to do this anyway for new language features, but why complicate more?). To add salt to the wound, non LTS releases are only supported until the next JDK so you need to adapt your project for every few releases because of this. Netbeans *still* doesn't have a way to convert a non modular JavaFX application(where JPackager would've been used) to a modular one easily, and modules were released with *Java 9* and many third party libraries still haven't moved to modules yet either(not that I use them, I've just read elsewhere that they haven't). I literally have a non modular JavaFX program that used to use jPackager that doesn't even compile anymore because Apache Netbeans 9 still hasn't added any code to remove jPackager from the ant scripts(or whatever). The project isn't worth anything but that isn't the point. Why break support for it if it isn't hurting anything? Why introduce something and then abort it like it's an unwanted baby? Isn't developing these features/tools/options and dropping them so fast costing time and money? If there is a completely legitimate reason like is the case with Swing interop(as stated before) then that's understandable, but some minor bug(like above) that could probably easily be fixed is just kicking yourselves. No one wants to utilize a feature/tool/option only for it to be pulled from under them all of a sudden for no good reason or a *PROPER* AND *COMPLETE* replacement. It happens so often you can't depend on any new feature/tool/option since you have no idea if it isn't just going to get removed a few JDK releases later. And no, a standalone SDK isn't a replacement for a JDK that has built in support for JavaFX. Does it continue to allow you to compile the project? Maybe? At what cost? HDD space, memory(see below), convenience, and reproducibility(multiple JavaFX versions potentially being used). I didn't even know about it until I compiled and tested it, but a "client" build of the JDK uses less memory than a "server" variant regardless of the application itself. Without being able to build JDK with JavaFX support baked in, my application would be unnecessarily allocating more memory than it needs to. Most JDK/JRE builds are "server" builds and not "client" builds and use around 250MB which is insane and will cause people to complain. If there is no other *PROPER* AND *COMPLETE* way to reduce the insanely high memory usage of "server" JDK/JRE builds, is that use case not enough reason to support it? (Side note: A "client" build of the JDK fails to finish a JavaFX test because it runs out of heap space. Guess I'll need to build a server and client variants from now on.) On 9/18/2018 7:30 PM, Ty Young wrote: The zip file "src.zip" located in rt/build/sdk/lib/ after building JavaFX from source causes a bugged build of OpenJDK with JavaFX integrated into it. The build itself completes just fine, it's just that resulting build has issues. Because a zip file isn't a supported module format, Netbeans spits out an error saying as such when attempting to compile a JavaFX application(unsure if the project being modular matters here or not, but it is.). It also seems to cause any attempt to build a new build of OpenJDK to segmentation fault using that same bugged
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
On 9/24/18 2:12 AM, Johan Vos wrote: > And it's only going to get worse as time goes on. Would it not be > possible to support up until the last JDK LTS(Starting at 11) release > for building JavaFX? I feel like maybe that would be more reasonable. This is a good question, and maybe in the future we might not be so quick to do this...or maybe we will. We should discuss this before we get to this point for JavaFX 13, a little less than six months from now. The choices for the model are: 1. Allow building JavaFX N with either JDK N-1 or JDK N. 2. Allow building JavaFX N with the most recent LTS or later. Choice #1 will allow JavaFX to better keep pace with JDK features (API or language features). Choice #2 will allow JavaFX to build and run with the most current, stable JDK LTS at the cost of not being able to use newer JDK features. One of the reasons Java is moving to a fast release cadence is because today, this is required to stay relevant in a fast-changing landscape. I think we need to do the same with JavaFX. We should be able to leverage the latest and greatest advances in the JDK, since this will allow JavaFX to move fast as well, which is required to stay relevant. Maybe it's because I don't work for a large corporation, but I don't see this supposed "fast-changing" landscape. To me, it just looks like Java is trying to appeal to all the people from Python/C++/other languages who can't or have a hard time writing object oriented code by introducing a more lazy "functional" and "concise" way of programming. The amount of actual meaningful updates to the language in 10 and 11 in my eyes is fairly small, which is somewhat expected with the faster release cycles. If there was actually a "fast-changing" landscape, I would think that there would more meaningful and useful updates rather than the 50/50 "functional and/or concise"/other misc updates that has been the case for JDK 10 and 11. Personally, whatever was updated that resulted in Netbeans properly using the OS's Look and Feel was the only worthwhile update of the entire JDK 11 release IMO, but I digress. To be clear, I'm not that concerned about breaking compatibility with older versions of the JDK because of API updates/introductions/removals or new, better tools being introduced. I'm more concerned about backwards compatibility being broken for stupid reasons like new lazy language updates that have no actual value or can be done with older compatible ways just because people want to be lazy, "functional", and "concise" which has become a bit of a hot trend lately. If you want to run on the latest stable JDK LTS, the logical consequence seems to me you use the latest stable JavaFX LTS. There is LTS support available for both Java and JavaFX 11 and they are pretty well aligned. That's all fine and dandy except for the fact that you can't guarantee what JRE is being run if you haven't moved to Java 9 modules. What do you do, wait a few months after a new LTS is out and then update your application with new JDK/JavaFX features and say "tough luck" to anyone who is still using a previous LTS? What if a user has a newer JRE installed with a feature that exists on the previous LTS removed but not their newer JRE that JavaFX LTS depends on? I've never tried it, but I guess you could prompt the user to download a compatible JRE via a Swing GUI and use that to launch the application via a launcher... but that's just awful for so many different reasons. Having said that, there is no point in moving forward just for the fun of it. We also have to distinguish between changes in the VM or in the core Java API's. My opinion is that if a new feature is added to JDK N, we can really take advantage of it in JavaFX (N+1). In some cases, there won't be new features relevant to OpenJFX. But even then, I don't think we can't change our rules on a per-release case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). In general, I think developers updating from JavaFX 11-12-13 are also capable of updating the JDK from 11-12-13, so I prefer the coupling 1. Allow building JavaFX N with either JDK N-1 or JDK N. - Johan
