The Next Generation of Java Application Deployments
Java is constantly changing. Read more about the next generation of Java and the many changes to come!
Join the DZone community and get the full member experience.Join For Free
A lot is going on in the Java world. So, let's have a look at where we currently are.
Oracle Discontinues Java Web Start With Java 11
After discontinuing the Applet technology, which required browser plug-ins, Oracle has announced that they will also discontinue the Java Web Start technology.
Java Web Start, however, was a great way to easily deploy Java applications. It made sure that Java application deployments didn't fall too far behind the instant deployment feature of web applications — a point which already allows many companies to choose web applications over Java-based applications.
With Java Web Start gone, it will become harder, once again, to compete with web applications, if we don't find a good alternative.
Oracle Changed to a Biannual Major Java Release Cadence
Every 6 months, there will be a new "major" Java version, though the term "major" likely won't be used anymore and differences will be smaller than the 2-3 year cadence (see Java 8 -> Java 9 vs Java 9 -> Java 10).
With every "major" release, the support of the previous release seems to be discontinued.
As far as I understand, you will need to buy this LTS. If you don't, then it's recommended to upgrade to the next major version or find another distributor that provides updates (more on this below).
Interestingly, and to some surprise, the long-awaited Java SE 9 release with the new module system didn't become an LTS version and already has been superseded by Java SE 10.
Oracle also mentions that developers often package the JRE with their applications nowadays. End users should not need to install a JRE anymore.
Oracle and OpenJDK Binaries
While Sun started to open source the JDK with the OpenJDK project back in 2006 and Oracle continued this process, there are still some differences between the OpenJDK builds and the Oracle Java builds.
Now, Oracle plans to ship OpenJDK binaries for non-LTS releases, and with this shift, they also plan to finally close those technical differences that currently still exist.
Modular JRE and JLink
Together, with the JPMS (Java Platform Module System), which modularizes the JRE and can be used to modularize applications, Java 9 introduced a new tool called JLink.
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE. This should also make Java more appealing to IoT devices.
Since JavaFX 2.2 and Java SE 7 update 6, JavaFX has been included in Oracle's JDK. With JavaFX 8 and Java SE 8, the version has been aligned. Now, JavaFX has become available on the default classpath.
Recently, Oracle announced (see the link at the top) that, with Java SE 11, JavaFX will be removed again from the JDK.
With a modularized JRE, it might be more natural to let feature modules have their own cycles.
But, since JavaFX also includes native parts, it seems to me WORA (Write Once, Run Anywhere) will become a bit trickier — at least the packaging part of JavaFX applications.
Please read on for a possible solution.
The Java Packager Tool
JavaFX also introduced a new tool to create platform-specific native packages with an embedded JRE. With JavaFX 8, the tool has been added to the JDK as the javapackager tool.
Since Java SE 9, the javapackager tool integrates with the jlink tool.
In Java SE 11, the javapackager tool will be removed again from the JDK along with JavaFX.
There is a JEP request (JDK Enhancement Proposal) for a new jpackager tool. While I think we do need a tool such as javapackager/ jpackager, javapackager, and the proposed jpackager, they also have some major drawbacks:
- No cross-compilation support — You have to create the native packages on the target platforms, e.g. MSI-packages on Windows and deb-packages on Linux. Creating a one-click release pipeline is non-trivial.
- Platform-specific configurations — Each native package has slightly different requirements.
- No automatic security updates — The users have to rely on the application vendors to ship a new application version that contains a JRE with the latest security fixes (though not all security bugs might affect individual applications in the same way).
- Expensively managed deployments — In heavily managed enterprises, where the average users don't have local admin rights and can't install applications themselves, the processes of application deployments tend to get very expensive (up to several thousand CHF per deployment). This is another reason why enterprises nowadays tend to either Java Web Start or to web applications.
- Slow managed deployments — In these heavily managed enterprises, deployments also tend to be slow and can take up to several weeks until the application is deployed to the user machine. This also makes it hard to coordinate frontend deployments with backend deployments and is definitely not DevOps-friendly. This is yet another reason why enterprises nowadays tend to either Java Web Start or to web applications.
Given the above-mentioned issues with tools such as javapackager/ jpackager, which create application packages with an embedded JRE, I don't think this is the solution for the majority of Java applications.
On the other hand, I think that we should not require any more from end-users to pre-install a JRE, which likely doesn't fit for all applications anyway. However, it's unlikely that Oracle will provide another solution other than the jpackager.
If we need something different, then it will have to be community driven. So, I'm proposing here a new deployment model with the working title (likely to change): Drombler JStore. At the core of this deployment model is a new application store with first-class support for Java applications.
In general, most applications should be able to define a platform-independent package that also describes the dependencies to some managed native components, such as the JRE
The tooling will then make sure that the required native components are available on the end-user machine. The tooling will also configure the environment for the process which starts the application.
The currently proposed solution consists of 4 major software parts.
I've already written a PoC (Proof of Concept) for each of those, which I think can serve as a starting point. Please note that everything is still subject to change.
- Drombler JStore Client Agent:
- Current goals:
- Headless background service
- Targets: end-user devices (desktops, NAS, IoT devices,...)
- Download and update applications from Drombler JStore
- Download and update applications using a JNLP-like file
- Download and update native components:
- JREs (supporting multiple parallel major version installations)
- Custom runtimes created by JLink (supporting multiple parallel major version installations)
- JavaFX native components?
- Other native components, e.g. SWT?
- Support Security Manager
- Start applications in a configured environment
- OS integration:
- Desktop shortcuts
- URL protocol registration
- Run as native OS service/ deamon
- Access a first Drombler JStore REST service
- Download a JRE from Oracle
- GitHub: https://github.com/Drombler/drombler-jstore-client-agent
- Drombler JStore:
- Current goals:
- A free service (backend) run by Drombler
- Provide access to applications/application updates
- Provide access to native components and updates (JREs etc.)
- Search applications
- Rate applications
- Comment on applications
- Register vendors
- Provide vendor contact options
- A first deployed REST service is available (likely to change)
- Swagger: http://drombler-jstore-staging.us-east-1.elasticbeanstalk.com/swagger-ui.html
- Drombler JStore Client:
- Current goals:
- JavaFX-based rich client
- Remote management of multiple Drombler JStore Client Agents
- Discover applications on Drombler JStore
- Rate applications on Drombler JStore
- Comment on applications on Drombler JStore
- Register vendors
- Drombler FX-based rich client
- Initial multiple Drombler JStore Client Agent management support
- Pluggable feature support
- Connect to the Drombler JStore REST service
- GitHub: https://github.com/Drombler/drombler-jstore-client
- JAP Maven Plugin
- Current goals:
- Define a platform-independent application packaging format and metadata
- Provide Maven tooling
- Creates a ZIP-based package, which contains the application in a nested ZIP-file.
- GitHub: https://github.com/Drombler/jap-maven-plugin
- In the future, there could be similar solutions to other build tools, such as Gradle
Call to the Community
As mentioned above, if we need a different deployment model, then it will have to be community driven.
What do think about this proposed solution?
Do you have a need for an alternative deployment model?
Do you think we're running in the right direction with this proposed solution or did we miss something?
Contributions and Donations
Even for an MVP (Minimal Viable Product), there is quite some work to do.
Contributions are extremely welcome! The current code base is not very complex. You should be able to get started quickly. Please don't hesitate to ask me, if you have any questions.
We can use your inputs especially in the following areas:
- What should the platform-independent application packaging format and metadata look like to support your applications? What information is needed by the agent? What information is only needed by the discovery feature of the rich client?
- Help us to make sure the agents have the necessary native OS integration to support your applications.
- Help us to create a great user experience with the rich client (some UX and JavaFX skills required)
- Help translate the texts of the rich client to different languages (i18n/ l10n)
- Help us to get the basic features of the agent right
- File enhancement requests for the various components
- Join the discussions in the issues or on Gitter.
- Help with the documentation (GitHub Pages, README files)
Since the proposed solution requires a backend, this will also require some resources to run the service. Any donations are welcome!
Here are some further blog posts about similar topics:
A lot is going on in the Java world. But these changes also provide opportunities for new solutions.
Join and help to shape the next generation of Java application deployments!
Published at DZone with permission of Florian Brunner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.