TornadoQt? Dear all, I work at CERN as the leader ...

# tornadofx

[vbaggiol]

TornadoQt?
Dear all,
I work at CERN as the leader of a team who writes Java software to control the LHC and the other accelerators. We have accumulated several MLOC of Java code, using Spring on the serverside and Swing or (more recently) JavaFX for the GUIs.
I have used TornadoFX and like it very much – it makes Java GUI development fun again! Well done and thanks a lot! TornadoFX gave me a lot of hope for the future of JavaFX. However my optimism has faded away recently when I read the Oracle whitepaper “Java Client roadmap update”, which says that Oracle will stop support for JavaFX after 2022, while continuing support for Swing through at least 2026.
So what about using Qt instead of JavaFX? In the podcast “Talking Kotlin” about TornadoFX, @edvin mentions that they considered to do a Tornado DSL on top of Qt (at 21m40s), which also seemed interesting in conjunction with Kotlin Native (at 32m).
Any ideas or plans in this area? If yes, I would be interested in participating…
Best regards,
Vito Baggiolini

[altavir]

Dear Vito. I think you got it wrong, Oracle does not state that it will discontinue JavaFX. It says that Java 8 will be supported until that time. It is planned to decouple JavaFX from the JDK distribution and so it will be developed by OpenJDK community as a separate project. I think it will benefit JavaFX quality, not diminish it.

By the way, I am very surprised and happy to know, that CERN people use Java technology. I am working at Institute for nuclear research, Russia on non-accelerator physics and I use Java (and now Kotlin) both for simulations and visualization for a long time. I and my team would be very happy to participate in Java-based software development for particle physics as a part of collaboration.

[abhinay]

I tend to agree with Alexander. Decoupling of JavaFX will only benefit the platform in the long run.

[altavir]

I think that at least it will speed up feature releases. For now they have the same release table as JDK itself (though it should be sped up as well).

[vbaggiol]

Thanks for your replies! I hope you both are right, because I also find JavaFX a very good library and TornadoFX makes it very enjoyable 😉.
I have seen in the other thread that this community is quite optimistic when it comes to interpreting the future of JavaFX. I would love to join this optimism, but when it comes to reading the Oracle statement, the future looks much more bright for Swing than for FX... comparing the statements about Swing and JavaFX in the whitepaper, I see much more commitment to Swing.
Also words like "niche" and "eroded" used for FX don't sound positive to me...
Am I missing some additional information?

Maybe we should continue this discussion in the other thread?

[altavir]

I think it is a question of official support, not the perspective. Since Java 9, Oracle tries to move the focus of development from HotSpot to OpenJDK group. JavaFX is assumed to be mature enough to be started as a separate project since Java 11( which expected next year). I do not read all of the oracle statements, but what I read suggests that they still consider JavaFX to be primary framework for UI.
JavaFX lost a bit of popularity, but not in favor of Swing, which is used only in legacy applications. The main adversary is a web-bases visualization.

[altavir]

So the question is not about what will be included in JDK, but what package will be developed further. I do not think that anyone will work on Swing.

[carlw]

I think adding a layer of Kotlin Native code on top of an established Qt product would be difficult to maintain as would reconciling the Qt ecosystem with TornadoFx. I imagine you’d be fighting the API at every turn and native binding upgrades would threaten the stability of the platform.

[carlw]

I think tornadofx is best off with javafx. That platform got tornadofx to what is is today, freeing the framework up from the messy details of cross platform development.

[carlw]

I don’t think there’s a clamoring for Swing. I’ve only heard a few laments about JTable behavior over TableView. Javafx separates the presentation better with css and the new skinning changes should be better for component development.

[vbaggiol]

@altavir having "official support" from Oracle makes some difference, doesn't it?
I'll keep an eye on how the OpenJFX project evolves now. There have been a few interesting threads of discussion on their mailing lists, e.g. about moving to github, and about the right workflow to pursue. I hope that they manage to send the strong signal to the community which IMHO is needed to keep and strengthen the open-source community.
http://mail.openjdk.java.net/pipermail/openjfx-dev/

[edvin]

@vbaggiol Very cool to hear 🙂 My hope is that the decoupled JavaFX will be possible to fork down the road, so that we can maintain our own cross platform UI toolkit, and start converting it to Kotlin. This will allow us to fix some bad design decisions in JavaFX and squash long standing bugs. I looked at Qt, but the license and commercial aspect might be an issue. I agree with the others here that the decoupling of JavaFX from the JDK is a very good thing, even if we don't end up forking. We could finally much easier contribute and fix bugs in JavaFX ourselves. Just setting up and compiling the whole JDK to be able to debug and compile JavaFX now is extremely painful. The future is bright for JavaFX and TornadoFX IMO 🙂

[vbaggiol]

@edvin thinks a lot for your reply. I definitely think that JavaFX has a capable community that could make it thrive (again). The next few weeks or months will show...

[edvin]

@vbaggiol If it doesn't pan out (which I'm sure it will) let's revisit Qt 🙂