Countdown to OpenJFX 11: Early access on embedded devices now available
September is a busy month; both JDK 11 and OpenJFX 11will be released shortly so everything is falling into place. Case in point, Gluon is making JavaFX available in early access for embedded devices, e.g. the Raspberry Pi.
We’re less than a month away from OpenJFX 11 so everyone is hard at work trying out the early access builds. Speaking of OpenJFX early access builds, No. 25 is here.
By the way, Gluon just made JavaFX available in early access for embedded devices, such as Raspberry Pi. You should know that this release is based on the exact same code that is powering JavaFX on desktop systems, according to the blog post announcing the news.
If you’d like to learn more about the steps that need to be taken in order to get a JavaFX 11 application up and running on a Raspberry Pi, check out this document.
Update August 22, 2018
We’re only a month away from OpenJFX 11 so everyone is hard at work trying out the early access builds. Speaking of OpenJFX early access builds, No. 23 is here.
Say hello to OpenJFX 12: OpenJFX to follow the same core principles of Java’s new release cadence
Gluon recently announced that they have increased their investment in OpenJFX so in addition to working side by side with Oracle, as well as with individuals and developers from a number of companies to release OpenJFX 11 next month, they are also offering JavaFX Enterprise Support, where they maintain a Long Term Support version of OpenJFX 11. Why is that, you ask? Because OpenJFX will follow the same core principles of Java’s new release cadence and development has started on the next version. This way, “developers don’t have to wait years [anymore] for a feature or bug fix to be in a released version.”
As exciting as this may sound, OpenJFX’s six-month release cadence will have the exact same problem Java has right now: not everyone wants to jump to a new version every six months. This is where the JavaFX Enterprise Support comes into play. Those who subscribe to this support package will have access to builds that contain critical or important fixes that are backported to OpenJFX 11.
Last but not least, if you’re wondering what’s up with the upcoming release, here’s what Gluon has to say in the latest blog post titled JavaFX 11 Release and Support Plans:
Since things are progressing as planned, we are confident we can release JavaFX 11 GA in the second half of September, close to the release of Java 11. A JavaFX 11 stabilisation repository has been created, in which only blocking issues will be fixed. From this repository, Gluon has been given responsibility for building and releasing JavaFX 11.
Update June 14, 2018
JDK 11 represents more than just the end of the road for Java EE modules — it’s also the end of the road for JavaFX — kind of. Three months ago, Donald Smith, Sr. Director of Product Management at Oracle announced in a blog post that starting with JDK 11, JavaFX will be available as a separate module, decoupled from the JDK.
But we shouldn’t cry over spilled milk; the release date for OpenJFX 11 is getting closer. In fact, it should go GA one week before JDK 11. Kevin Rushforth, lead of the OpenJFX Project, announced in a message to the OpenJDK mailing list that they wish to release OpenJFX 11 “at the same time JDK 11 ships (or slightly sooner).”
Proposed rampdown schedule for OpenJFX 11:
2018-07-09: RDP1 (a.k.a. feature freeze)
2018-08-27: freeze for GAC build
Now let’s have a look at JDK 11’s schedule:
2018-06-28: Rampdown Phase One (fork from main line)
2018-07-19: All Tests Run
2018-07-26: Rampdown Phase Two
2018-08-16: Initial Release Candidate
2018-08-30: Final Release Candidate
2018-09-25: General Availability
If everything goes as planned, JDK 11 should be released one week after OpenJFX 11.
Rushforth proposed a shorter time after RDP2 than the JDK because it is unlikely that they will need “the long back end of a full JDK feature release (not as many moving parts or stakeholders).”
Although there’s not much of a difference between the JDK schedule and the FX schedule, there are at least two modifications, Rushforth wrote:
Since this is our first unbundled release and there are likely to be plenty of bugs that need fixing during RDP1, so I propose to postpone forking the repo until RDP1. This means a 4-week downtime where there is no place to push new features/enhancements unless they are critical to OpenJFX 11 (in which case they will be an exception). I think this is a reasonable trade-off for this release
I don’t plan to propose any restrictions on P4 bugs before RDP2. The focus should be on more serious bugs, and we likely won’t fix many P4s, but if a safe P4 bug fix is proposed, reviewed, and tested, then I see no reason not to take it between RDP1 and RDP2.
For more information about the open source home of JavaFX development, visit the OpenJFX Wiki.
Was decoupling JavaFX from the JDK an inspired idea?
Development of JavaFX started in 2005, but it was officially introduced two years later at JavaOne. The technology was fully open-sourced in 2011 and, in 2012, it became part of the Oracle JDK download. Six years later, we’re saying goodbye to this arrangement; JDK 11 will mark the end of the javafx modules as we know them (a.k.a. part of the Oracle JDK download).
Johan Vos explained why it makes perfect sense to move the development of JavaFX to an open system. Check out his latest article here.
The core of the JDK is a wonderful piece of art that is maintained by very talented engineers. In order to guarantee the quality of this core, especially with fast release cycles, whatever components that can be maintained outside of the core should be maintained and released separately.