Zulu Community

Discussion on Java FX in Zulu

Updated on May 5, 2017 in General Zulu Questions
5 on December 20, 2016

We have had two threads in this forum on Java FX, though neither provided concrete guidance on how to get Zulu to officially support it. This post changes that: we now have an internal objective to move ahead with OpenJFX in Zulu in early 2017. This topic covers our goal, plan, and procedure. Please click to Follow this topic if you care to engage with the Zulu team on moving this project forward towards a near term community release.

  • Liked by
  • imario
Reply
3 on December 21, 2016

For reference, here were the prior two OpenJFX related threads:
http://zulu.org/forum/thread/add-openjfx-to-zulu/
http://zulu.org/forum/thread/the-azul-system-does-not-compile-the-openjfx-because/
They are carried over from the old forum once hosted on Azul.com, and migrated here.

Chris Newland provided this workaround to build OpenJFX and apply it atop Zulu:
https://www.chrisnewland.com/add-javafx-support-to-azul-systems-zulu-jdk-using-openjfx-383
This has been the only guidance. Until now.

I put the following text into the requirement spec. I welcome anyone to provide feedback on adequacy of scope and testing!

Create a new application component, herein described as “Azul JFX”, comprising the Base, Graphics, Controls, and FXML components of OpenJFX. The Swing, SWT, Web, and Media components of OpenJFK are considered deferred scope and excluded from initial deliverables.

Azul JFX should be validated to work on Zulu 8 on Windows, Linux, and Mac on Intel x64 platforms. Azul JFX should be validated to work on Zing 8 on Linux x64. Azul JFX should be validated on Zulu Embedded on Linux for ARM32 and ARM64, on Windows and Linux for x86 and Atom, and–once available–on Linux on PowerPC.

On Linux, both local workstation and remote X windows should be validated.

On workstations, the video resources are managed by OS and drivers, so any display technology, even GPU based systems, should work out of the box.

On embedded targets, the video resources may have additional vendor constraints. The Zulu Embedded team is encouraged to use the Reference HW concept to focus on a few initial HW options, then expand as customer demand and order backlog indicates.

Azul JFX overlay must maintain a minimum level of applicable Zulu and Zing versions where it can be applied.

There is no requirement to have to uninstall Azul JFX overlay from a Zulu or Zing once it is installed. Users may uninstall the whole Azul product and take Azul JFX out with it, and start over with fresh product install.

There are no obvious benchmarks for what constitutes “sufficiently good” performance for the Azul JFX component. Engineering is strongly encouraged to locate and publish benchmark values, based on something simple like http://mihosoft.eu/?p=486 FXBenchmark01, or another portable benchmark of your choosing.

The objective is to match – and no requirement to exceed – Oracle’s own JFX performance on like hardware and OS combinations.

The official deliverables will reach the Zulu download pages in waves as they get built. If you are interested in doing any pre-release testing, we’d ask for you to provide the details of the target system you plan to exercise. With enough participation and coverage, we’d setup a matrix of tested systems, very similar to the Assignments table on the OpenJFX wiki here: 
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Thanks in advance for keeping Zulu better and more relevant every release.

Matt

on December 21, 2016

If you mean with “Web” the javafx.scene.web.WebView component, then I think this is an important control for pretty much every JavaFX application. Not having that would avoid me (and I think many others) from using your distribution.
Not sure about “Media”. If deferred, then I think it has to follow in the next release of your distribution as making noise (erm sound) is also an important thing sometimes.
Swing and SWT I guess can be deferred indeed.

on December 29, 2016

I think this is a really profound and well balanced plan. It will be a great step forward for many JFX app developers.
Unfortunately our app relies on the SWT integration and the browser features of JFX. Probably like a couple of others we use JFX in a mixed SWT/JFX application using the great efxclipse framework. We use JFX to replace the – over many years – broken browser widget of SWT with the JFX WebView. Unfortunately you excluded SWT and the browser features from your plan. For sure for good reasons, because you would get dependencies to image, fonts,may be qt libraries, …. :-(

Regards,
Theo

on May 5, 2017

Having OpenJFX in Azure JDK build would be great. We are  trying to replace Ubuntu package with your build of OpenJDK as a secondary compiler of Corda (along Oracle-JDK), but the build fails on some JavaFX stuff.

Show more replies
  • Liked by
Reply
Cancel
0 on December 21, 2016

Hi Matt,
This sounds great :)
Currently you can also take a pre-built JavaFX overlay binary from my open-source nightly build server https://www.chriswhocodes.com and unzip that into a Zulu JDK installation but having it included will be even better.
Hopefully the Media components will be supported eventually (deferred due to licensing?) as Zulu+OpenJFX on ARM is somewhere Azul could make a lot of friends in IoT after Oracle dropped JavaFX from their ARM JDKs.
If you need a benchmark to test your JavaFX performance you could try: https://github.com/chriswhocodes/DemoFX

Cheers,
Chris
@chriswhocodes on Twitter

  • Liked by
Reply
Cancel