Does this library supports java 11 ?

[Kapil-Bhattarai]

[edvin]

No, not yet. There is a Java 11 branch called jdk10 which will eventually become the official Java 11 compatible release, but I’m too pressed for time to complete it right now myself. It is working for everything I’ve tested it against, but it still needs more testing.

[LouisCAD]

@edvin Would you submit a draft PR (new GitHub feature released less than 24 hours ago) so we can subscribe to it and be notified when there's an update or it is merged?

[edvin]

We'll probably do a release or two before it's merged, but I'll make sure everybody knows as soon as something is ready to test. Unfortunately, I don't have much time these days, so things are moving slow.

[DanySK]

Hi @edvin, sorry for bothering you. Can you (even roughly) estimate when a Java 11+ compatible version of TornadoFX will get released? Will such release still be compatible with Java 8, or will we need (for projects meant to run on both platforms) to use different releases?

Thanks

[edvin]

I can't, really. I have no time these days, and it will be like this for a couple of months more I suspect. The Java 11 version will not be backwards compatible, due to changes in both the JDK and the decoupled JavaFX. The upgrade path will be pretty simple though, a matter of swapping out the runtime and changing a few function calls due to depreciations being largely removed in the Java 11 version.

[DanySK]

There are reflection accesses which won't be doable with the module system:

java.lang.reflect.InaccessibleObjectException: Unable to make protected javafx.collections.ObservableList javafx.scene.Parent.getChildren() accessible: module javafx.graphics does not "opens javafx.scene" to module tornadofx
	java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
	java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
	java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
	java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
	tornadofx/tornadofx.FXKt.getChildrenReflectively(FX.kt:662)

[nlbuescher]

So with Oracle seemingly having archived jdk8 (you have to log in to an Oracle account to download it now), how can a Kotlin programmer get involved in making this release happen? Is there a todo list we could tackle?

[edvin]

Most of what I have tested seems to work, so any help in actually testing it and pointing out issues would be great. We might be ready to do a snapshot release and let more people start testing!

[DanySK]

@edvin if you could mark an RC release and push it on Central, I'd gladly test it on Alchemist (@vuksaa get ready)

[edvin]

OK, will get to it soon, in the middle of moving so I need a few days.

[Romanow88]

Would also give it a spin with our app.

[simplesteph]

FYI

repositories {
    maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}

dependencies {
    compile 'no.tornado:tornadofx:2.0.0-SNAPSHOT'
}

[Megerian]

Thanks a lot for that repository! It now works with Java 11.

[DanySK]

@simplesteph, is this package still compiled with Java 8 compatibility? I'd like to depend on a single tornadofx distribution for a software meant to run on both J8 and J11+.

[opensource21]

@DanySK as mentioned above this is not possible.

[DanySK]

@opensource21 I am mostly referring to providing code compiled with version 52.0. I actually guess it's not possible to do something else, AFAIK Kotlin can only compile Java 6 or Java 8 bytecode.

I believe we should invest some time (if someone has already, much better, but I missed details) into understanding if it is possible to provide a version of TornadoFX that works for both JavaFX8 and JavaFX11. The changes I personally made (but I was working on a JDK10 branch created by someone else) should not compromise compatibility with JFX8.

Of course this would require special care client side to override dependencies. And of course it would be not recommended nor supported Tornado-side. Yet, if no JDK9+ specific APIs are used (I do not know if they are, but given the kotlin stdlib covers most use cases it's fair to suppose they are not), and if there are no API changes besides the ones I worked on (which were mostly reflection issues), then there is some chance that TornadoFX 2.0.0 works on JavaFX8 as well.

@vuksaa I need you to give the snapshot a try on Alchemist. Make sure everything works with Java 11, if it does, take a chance and force Java 8, see what happens. I can help ironing out issues.

[bekwam]

There are source incompatibilities. Take a look at DataGrid.kt. The current (8) master uses

import com.sun.javafx.scene.control.skin.CellSkinBase

While the jdk10 branch uses

import javafx.scene.control.skin.CellSkinBase

[DanySK]

I see. No way then. Thanks!

[xqdd]

If there any issue, please point out.

Tornadofx java 11+ maven template

[DanielSWolf]

Has there been progress with testing? I'd love to use a current version of OpenJFX! ☺

[rossdanderson]

So far I am running without problems - if you'd like to take a look it's here . It set up for Java Modules with Java & FX 12, Gradle with Kotlin DSL, and fairly heavy coroutine use (including a ported version of TornadoFX's Command) so it's "bleeding edge" in a few ways. The UI itself is still fairly simple so I can't say you won't run into your own issues, but if you just need to get setup then I hope it is helpful.

[Romanow88]

Looks also good to me on jdk 11 + openjfx 12.0.2

[DanielSWolf]

Thank you! I'll give the snapshot version a try, then! 😀

[nlbuescher]

Just finished porting my somewhat large (multi-module gradle) project to jdk11+. Some points I ran across:

1. It is much much easier to create a non-modular application than to create a modular one (ie skip the module-info.java files in your app)
   • for a non-modular fat jar, your main method needs to be in a class that doesn't extend javafx.application.Application
   • to include javafx native libraries for all platforms, use the runtimeOnly configuration to add the win/linux/mac artifacts (or whatever they're called), and copy dependencies from the "runtimeClasspath" configuration in the jar task.
2. I could not get controlsfx to work in a modular project.
   • similarly, I was using tornadofx-controlsfx with jdk8, which does not have a version that supports controlsfx 11
3. I had some really weird errors while setting up the fat jar copying while using the gradle kotlin build scripts, so I switched back to Groovy for that which made it work fine. (EDIT: this may be related to my module interdependency setup)
4. The jdk10 branch is several commits behind master so I had to change some spots in my code where I was using newer functionality.
5. (EDIT2) I was also not able to retrieve resources using the Image(resources["/logo.png"]) with a modular setup. Was failing with a NullPointerException, ie the resource could not be found. I tried several different path formats, and even using Image("file:logo.png") did nothing.

What finally helped me get it working was the openjfx samples

The "application" plugin was not necessary in IntelliJ, I only needed a run configuration that executed my main function.

The new TornadoFX version seems to work just fine from what I've found, after getting the kinks worked out of the whole jdk11 module and dependency mess.

[edvin]

Thank you for this valuable feedback. I'm close to porting a large app myself, but need help in porting changes from the J8 branch to the new branch. Once the port is complete we'll do a 2.0 release as soon as possible. It breaks my heart that I don't have time to work on this as much as I had before, and I always think that "now" will be the time that I can reengage, but projects keep coming in the way :(

[pavlus]

About support of both Java 8 and 9+, this probably can be achieved with JEP-238 (multirelease JARs), but it will require some more work.

[edvin]

I'm not sure that will be worth it. I think we'll migrate to the 2.0 branch and keep adding bug fixes to the Java 8 branch once we've made the switch, but we'll keep the deployments separate. Less headache :)

[pavlus]

Also, as far as I understand, consumers still will be able to use 1.7.x and place version 2.x.x classes to release 9 path by repacking TornadoFX JARs to single one, if they realy need it.

[ctadlock]

Any updates on a plan for tornadofx to support Java 11?

[nlbuescher]

I'm currently using the 2.0.0-SNAPSHOT version without issue.