The state of JVM desktop frameworks: introduction

I'm interested in GUI applications since I've starting coding. Building a back-end app that manages teraflops of operations is an impressive engineering feat. But the feedback cycle when developing a desktop app is much shorter. That makes it, at least for me, much more motivating. This is even truer for side-projects. In this focus, I'd like to assert the state of JVM desktop frameworks.

This first post is an introduction, framing the general background, and browsing through the frameworks I've encountered.

Background

Let's face reality: in the fight of web apps vs. desktop apps, the former ones have won. It's just less expensive to deploy them. That's the reason people started to push for them, though the HTML-JavaScript-CSS combo offered a poorer alternative at the time.

Web apps are now ubiquitous: in the past, I've even developed web apps for less than 5 users. Whether it was worth it or not, I leave it up to you.

The victory of web apps pushed desktop apps toward obsolescence. Most of those that escape this fate leverage the Electron framework e.g. Slack, VS Code, Postman, etc. JavaScript and Electron have several benefits:

A lot of developers know JavaScript. A JS-based framework makes smart use of this available workforce.
JavaScript doesn't require any platform. Such applications are self-contained.
Electron is available as Open Source, under the MIT License, and managed by the OpenJS Foundation.

On the flip side, Electron is notoriously infamous for being resource-hungry.

AWT and Swing

The Abstract Windowing Toolkit was the graphics framework originally included in the JDK. AWT relies on native resources of the operating system: AWT components are heavy-weight. Java 1.2 introduced Swing, an alternative to AWT, which offered lightweight components.

I started learning Java two decades ago and tried to learn Swing as well. But at the time, I didn't work on any desktop app projects during my job. I also didn't have time for any personal side-project. Yet, my interest was there.

Swing offers a way to customize the Look-And-Feel of an app. There a default LAF, but an Operating System LAF is also available. Because Swing draws components by itself, even with the latter, components always look a bit different from the OS native ones. IntelliJ IDEA is a famous example of a successful Java application.

Over the years, I kept trying Swing, but also other available options.

SWT

The first such option was actually a hack of the popular Eclipse IDE. Eclipse used neither AWT nor Swing. Developers had designed their graphical framework, the Standard Widget Toolkit. SWT relied on native libraries.

Cunning developers utilized the fact that Eclipse was Open Source to build their applications on top of it. After a while, the Eclipse project recognized it formally. They worked to improve the API, the documentation, the libraries and called it the Rich Client Platform.

Over the years, I played a couple of times with SWT. I liked the way it used the native OS components a lot. That gave a real native feeling. One didn't know a Java application was underneath.

Eclipse also released a higher-level abstraction on top of SWT called JFace. Don't confuse it with JSF, it's not related at all.

The biggest issue with SWT was that the API was unstable. It had started as an internal framework, and it showed. Upgrading to a new minor version broke my code.

Another issue that affected me less comes from the dependency on OS components. Java is designed to be cross-platform: hence, each Java runtime comes with its component bindings for the OS it's installed on. SWT also has bindings for each OS, but on the JAR level. Hence, applications need to bundle a specific JAR for each OS it needs to be deployed to.

Flex

One must remember the context 15 years ago. HTML 5 was still a W3C draft. Browsers were different in their display of HTML. Sometimes, they also had different interpretations of JavaScript. Creating a true cross-browser application was a large time investment.

In 2004, Macromedia released Flex, a framework able to create Flash applications from:

GUI definitions defined in XML, using a specific FXML schema
Behavior coded in ActionScript

The sole requirement was for the browser to have the Flash plugin. 90% of the browsers had it installed at that time!

The widgets offered a much better experience than their HTML equivalents. For example, filtering in a combo-box had been available on every heavy client framework for ages. Filtering was not impossible, but a mess with the HTML and JavaScript. Flex was able to make it easy again.

It also allowed developers to implement applications that looked acceptable even with poor front-end skills. Plus, the look-and-feel was consistent across all browsers. To me, this was more than an alternative to the crummy JavaScript spaghetti code: I believed Flex was the way to build applications.

Then came the iPhone. It drastically changed the way people used the Web, from desktops to mobiles. Now, the problem was that Flash used a lot of energy (and to be honest, this was also a big security risk). Steve Jobs banned Flash from iPhones to save on energy. With the rise of mobiles, this made Flash less and less attractive for developers to use.

In the end, Adobe, which had bought Macromedia in 2006, gave the technology to the Apache foundation. I'm afraid this was the last step before the end: the latest release is from 2017, and the latest commit in the Git repository is 9 months old.

Other attempts

The death of Flash, and the rise of HTML 5 and JavaScript, didn't happen instantly. For a long time, there was no clear winner. During that period, choosing one over the other was the nightmare of architects.

The OpenLaszlo Open Source framework tried to solve this cleverly. It provided a neutral model to develop applications. At build-time, one could choose Flex or HTML+JavaScript as the target.

The end of Flash made OpenLaszlo irrelevant.

I'm aware of two other initiatives:

Mozilla proposed XUL, a way to define graphical components
Microsoft came up with Silverlight, a Flex competitor

Both are now obsolete.

JavaFX also deserves a mention. The 1.0 version was released in 2008, around the time Flex was already well established. This was not even comparable. Interestingly enough, Oracle continued the development effort: after the acquisition of Sun in 2010, it released 2.0 in 2011.

My understanding is that JavaFX is not part of the JDK as of now. The Gluon company seems to be leading its development effort. It makes JavaFX available as a standard library JAR, published on Maven Central (and as a regular download).

Deploying Java desktop apps

As I already mentioned, the Web previously provided a poor User Experience compared to thick clients. Yet, it won the battle. I believe the reason is two-fold:

Thick clients are either dedicated to a specific OS, or require a platform e.g. a Java Runtime Environment.
Deployment of an app on a single server (or even a cluster of them) is easier and less time-expensive than on each user computer

For internal users, neither argument holds. Computers inside a company are centrally managed (or should be) by a sysadmin team. Thus, one can install any software remotely via the network. Enterprises have been using such dedicated software for ages.

In the Java world, a couple of solutions were specifically designed for that.

Java Web Start was the solution offered by Sun, as part of the Java platform. With JWS, one creates an external deployment descriptor using the JNLP format. The descriptor defines: the class to launch, optional dependencies, JVM arguments, etc.

The descriptor file is then made publicly accessible, for example, hosted on a web server. JWS can parse it, download the required dependencies, and launch the JVM accordingly.

JARs can be automatically updated via JWS. JWS can download only the difference between the installed JAR and the to-be-downloaded JAR. Even better, if the patch has a bigger size than the JAR, it downloads the latter.

If the application uses a shared database, evolving the schema can be an issue. For example, how to synchronize updates between the different clients and the database? The development team can design the application, so it cannot run unless it's above a specific version.

Oracle deprecated JWS in Java 9 and removed it from Java 11 distributions. It's now available as an Open Source GPL2 project and sponsored by the Karakun Swiss company.

Another deployment option is available for applications using SWT. The IDE offers the ability to automatically download plugin updates from configured remote sites. This feature comes from a module called RCP. Once you've installed the application, RCP takes care of downloading and installing the latest version. You can use RCP to build applications and enjoy the automatic update feature.

Conclusion

Web applications have won the fight against desktop apps. But Java desktop applications are still relevant inside a company. All the technological components are freely available: the JDK, and the libraries.

In each future post of this series, I will develop a simple application using a single technology. Next week, we will have a look at Swing.

To go further:

Originally published at A Java Geek on January^3rd 2021

Blog