JAXenter: Hello Dirk and thanks for taking the time to talk to us. JavaFX 13, or OpenJFX 13, is going to be released on September 10th. Can you give a little insight on what this release will have in store for developers?
OpenJFX 13 brings new features, bug fixes, and better basics for the further development of JavaFX. Highlights include support for native rendering, support for e-paper displays, and upgrading the Webkit engine to version 2.24.
In a cloud native world enamored with microservices and serverless, meet Quarkus – Java’s brilliant response to technologies like Node.js, Python and Go that had proven quicker, smaller and arguably more nimble. Donload your free beginner’s tutorial written by JAX London speaker Alex Soto.
RESOLVING TECHNICAL DEBTS IN SOFTWARE ARCHITECTURE
Dr. Carola Lilienthal (WPS – Workplace Solutions)
KEEPING UP WITH JAVA: LOOK AT ALL THESE NEW FEATURES!
Simon Ritter (Azul Systems)
CLOUD NATIVE COMMUNICATION: USING AMBASSADOR AND CONSUL CONNECT WITH JAVA APPS
Dr. Daniel Bryant (Big Picture Tech Ltd)
JAXenter: What is your personal highlight of this release and why?
Among the new features, support for native rendering clearly stands out. With a public API (without tricks and workarounds) it is possible to share memory between the JavaFX application and native applications and thus integrate technologies like OpenGL, D3D or, in the future, Metal (from Apple) into your own applications. Extremely graphic-intensive applications such as CAD systems, 3D editors or games could be implemented with JavaFX.
SEE ALSO: JavaFX 13 release interview with Johan Vos
JAXenter: This is the second release under the new release schedule, what are your thoughts on this? Is the “half year per update” approach reasonable or will the schedule eventually change to a quarterly or yearly release?
The coupling to the release cycle of the JDK provides structure and predictability on all sides; I consider this to be very important, especially at the moment. There has been a lot of change in JavaFX since Java 8 – APIs have changed, JavaFX has been decoupled from the JDK, and IDEs and projects that want to use JavaFX have to be configured differently. This was not always easy for developers to digest and caused some irritations, resulting in the adoption of JavaFX not being encouraged. A freer release policy could turn out to be another stumbling block.
JAXenter: JavaFX is not part of the official JDK release anymore for quite some time now. Did this have a positive or negative effect?
I have said from the beginning that I see the decoupling of JavaFX from the JDK as positive. JavaFX gets its own identity, its own processes, its own community, its own pace. Everyone noticed how much the development of JavaFX was slowed down when it was coupled to the JDK development process. Previously, all update releases of Java 8 had new features and real progress. After that it became very tough. Since JavaFX was released again we see progress and the will of the community to advance the toolkit.
SEE ALSO: OpenJFX to follow Java and migrate to GitHub
JAXenter: Next up is JavaFX 14, any major changes planned for this release or the near future?
JavaFX 14 will probably be the first release developed completely on GitHub. Work is currently underway to move the repository there (there is currently only a mirror on GitHub). This should simplify all processes and also ensure that more and more developers can participate in the further development of JavaFX. In the past it was not easy to build OpenJFX, that should change soon. As far as new features are concerned, it is still too early to say anything about it. This will become clear as soon as 13 is through the door.
Thanks very much for talking to us!
The post OpenJFX 13 – “JavaFX gets its own identity” appeared first on JAXenter.
Source : JAXenter
