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 is the 1st post in the The state of JVM desktop frameworks focus series.Other posts include:
- The state of JVM desktop frameworks: introduction (this post)
- The state of JVM desktop frameworks: Swing
- The state of JVM desktop frameworks: SWT
- The state of JVM desktop frameworks: TornadoFX
- The state of JVM desktop frameworks: Jetpack Compose for Desktop
- Distribution of JVM desktop applications
This first post is an introduction, framing the general background, and browsing through the frameworks I’ve encountered.
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.
- 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.
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.
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!
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.
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.
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.
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.