Contact Us
Java | JavaScript | React All Categories >

Knowledge Articles

JavaFX vs Swing vs Web

February 5, 2019 Greg Curtis 11 minutes, 33 seconds Java

It may feel like the world has moved to HTML5 and JavaScript for everything front-end. The norm is to dislocate tiers: the front-end built with HTML5/JavaScript/React/Angular/etc, and the back-end provided via REST API, GraphQL, or the Cloud. But this approach may not always be prudent, or even legal, and the need for a self-contained cross-platform Java application means that Swing, JavaFX, and others, remain relevant.

If you find yourself needing to choose an approach, this article may help you to resolve your position.

JavaFX vs Swing vs JavaScript, HTML5, Angular, React

This is aimed at being a "factual opinion piece". I'm not pitching these technologies against each other, rather I'll attempt to lay out the facts, before giving my opinion. It should also be noted that this is not exhaustive; I've touched on deployment, tooling and more, but tried to limit this to a 10 minute read.

Hopefully, I can save you some research time, or at least give you a head start. Come find me on LinkedIn to discuss the content, ask any questions, or let me know if I've missed something.

Java first. Let's keep it chronological and start with Swing.

Swing

As part of the then Java Foundation Classes, alongside AWT and Java2D, the later-renamed Swing has remained part of the core JDK since it's release in 1997. Yes, 1997.

Even before the release of JavaFX in 2008, Swing was labelled as the "ugly" Java GUI option, and has lived with that moniker ever since. A container/component hierarchy of uninspiring grey boxes. The natural Photoshop/Illustrator/Inkscape designer-to-developer pipeline hindered by the fact that there are no direct analogues for those beautiful designs in Swing.

Swing Provision & Future Support

Swing, AWT and 2D graphics are mature technologies. In recent years there have been additions, such as including support for high DPI displays, alongside some removals:

  • Java SE 11: very minor changes.

  • Java SE 10: touch keyboard additions, with a number of features removed.

  • Java SE 9: again, fairly minor.

  • Java SE 1.4 through to Java SE 8 enhancements can be found from here.

Importantly, there are no plans to deprecate Spring: Java has always emphasised backward compatibility. Swing development may have slowed, but even if you've been using it for a decade, nothing is going to suddenly break.

OK, it's time for the official line. According to the Java Client Roadmap, published in March 2018, we have the following:

"Swing (and AWT) will continue to be supported on Java SE 8 through at least March 2025, and on Java SE 11 (18.9 LTS) through at least September 2026.

Oracle has begun conversations with interested parties in the Java ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above referenced time frames."

The IntelliJ Swing Case Study

Several IDE's have been built with Swing: NetBeans, Oracle's SQL Developer, and interestingly, IntelliJ IDEA. Looking at the documentation for extending the IntelliJ platform, it's clear that a large number of custom Swing components have been introduced.

Now, on the surface this looks like a fantastic pitch for Swing, but IntelliJ has been around since 2000, and the idea of porting reportedly ~8.5 million lines of code (circa November 2018) of the plugin-complete IDEA Ultimate over to JavaFX, for arguably doubtable improvement, is likely extremely unappealing at JetBrains. There would be a business case if Swing could not fulfil requirements, but this is already a beautiful, capable IDE.

There are other good looking Java client applications out there. Before it became Vuze, the Azureus BitTorrent client was a prime example, though it turns out that was written using the Eclipse Standard Widget Toolkit (SWT), rather than Swing. SWT is outlined below.

Working with Swing Today

The landscape of Java and JavaScript continues to change. To remain as insulated as possible from that change it pays to rely on technologies that are likely to remain supported by both skills, materials, and web resources.

On a past (10+ years) project, we provided Swing touch-screens extending an Oracle warehousing environment. These were created using Project Matisse (now simply GUI Builder) in NetBeans. Yes, the technology has stagnated since, yet it's maturity and scope of resource should make maintenance and new feature additions fairly simple today. Even the Matisse generated code shouldn't be too difficult to work with outside of the IDE. The same could be also said of many server-side web technologies that have themselves fallen out of favour; from Wicket, through Struts, to Spring MVC. Even JSF, though I've never been a fan.

In building a new Swing application, a fairly complex UI is still quite achievable with a good choice of layout manager (GridBag, Border, Mig), and a Look & Feel (Substance , or Napkin), though these look laughably archaic when compared to modern web designs. Most functional UI's are going to be able to live with simple 2D, but 3D is possible via JOGL, which provides hardware-supported 3D to Java via the OpenGL API.

I've mentioned an alternative to Swing above, and that's the open source widget toolkit that is SWT. For all intents and purposes it resembles Swing, but is actually utilising native support, via JNI, where possible. SWT applications are still portable, and performant compared to Swing, due to those native aspects. I'm going to lump SWT in with Swing from here on: they are cut from the same cloth, and deployment issues the same for both moving forwards.

JavaFX

Introduced in May 2007 by Sun Microsystems, JavaFX allowed Sun to compete with Adobe Flash and Microsoft Silverlight in rich client development for desktops and mobiles. Oracle acquired Sun in 2010, and FX was subsequently open-sourced in 2011. It's fair to say that it never set the world alight, though has maintained a steady following. As time has moved on, these rich clients have largely been superseded by rich internet applications: the likes of JavaFX, along with Silverlight and Flash, have ceased to be strategy du jour.

Removal of JavaFX

JavaFX has now been decoupled from the JDK as of JDK 11, and given its own release schedule as part of the open source community. The move sees JavaFX now being developed as part of the OpenJDK project. It is now available for free, under the GPL, as OpenJFX. The removal of non-core modules from the JDK is not necessarily dismissive, rather a transition to standalone projects free to gather community support, allowing for a modular approach and leaner runtime bundles. The true nature of open source will see modules regarded as redundant simply losing support, traction, and being eventually retired.

Including and Deploying JavaFX Applications

Mirroring the Maven/Gradle approach, being able to pull down just what is required, feels like an improvement, e.g.

  <dependencies>
    <dependency>
      <groupId>org.openjfx</groupId>
      <artifactId>javafx-controls</artifactId>
      <version>11.0.2</version>
    </dependency>
  </dependencies>

The drawback, however, is that to create a cross-platform JAR could add up to over 100MB of dependencies. Using something like JPackage, or (gone in Java 11) javapackager, eventually to be replaced by JEP 343: Packaging Tool, should make bundling along with the runtime an easier proposition.

For more information, this article includes a useful case study around packaging and deploying a multi-platform JavaFX application using Java SE 11. As well as the tools outlined above, there is also mention of JLink, the now JDK-supplied module packager for creating custom runtime images.

The above article details the deployment of JavaFX applications as self-contained applications, which run outside of a browser, as we'd expect. But there's an elephant in the room, and that elephant is the web deployment of these applications. The Java Client Roadmap Update outlines that Oracle are encouraging Java WebStart and JNLP users to:

"... transition to other deployment technologies such as the jlink and/or third party packaging and deployment solutions before the end of 2020."

Graphics, Complexity, and GUI + Cloud

Chances are you're supporting existing JavaFX (and Swing) applications, rather than starting from scratch, but it can be argued that the desktop isn't going anywhere. A cloud-connected desktop application, unfettered by both browser and container, with responsive UX and a requirement for desktop horsepower, could be an appropriate venture. As an example on that note, the NASA contractors a.i. solutions provide the Deep Space Trajectory Explorer; a tool built using JavaFX to provide trajectory visualisation for manned deep space missions.

The JavaFX + Cloud approach is detailed here. Calculations are offloaded to the cloud via Gluon CloudLink, with the ability to utilise mobile via Gluon Mobile.

There are other case-studies that showcase JavaFX as a good fit for GUI's that need to "go beyond". One such example is PAMGuard, providing passive acoustic monitoring (PAM) for marine environments, which is transitioning from Swing to JavaFX, where creating custom interactive displays is proving easier than with the former.

Let's backup a little. Yes, these are impressive products, but so far from your average form or dashboard-based GUI it's silly, and it's obvious that Swing was either too difficult, or simply not an option here. One thing they do prove is that Java remains relevant, or at least a viable choice, for particular scenarios, especially those that leverage hardware accelerated rendering and 3D. It's also worth noting that GPU-accelerated JavaScript via WebGL is very much a thing; Deeplearn.js is used in machine intelligence, Propel in neural networking and computer vision projects, and then there's gpu.js and Brain.js, amongst others.

A note on use of JavaFX over Swing for complex graphics: it is possible to integrate JavaFX into Swing applications using the JFXPanel class; an option, alongside SwingNode that has support continued from Java SE 8 to the OpenJDK.

JavaFX Support

Gluon were mentioned several times above, a company likely most recognised by their Scene Builder product; a drag & drop RAD tool that remains free and open source.

Working with JavaFX via Scene Builder, at least initially, is practically a necessity. Whereas complex Swing GUIs were possible without tooling, the same can not be said for JavaFX. IntelliJ IDEA provides support for JavaFX as well as Scene Builder integration: it's just not a stepping stone, it's the preferred path.

It's worth noting that Gluon themselves have mirrored the OpenJFX source on GitHub, and argue that this increases the possibility of accelerated future enhancement.

The overriding concern is that it's tough to gauge the level of continued investment in Java FX. Gluon published some statistics around downloads back in mid-2017, but compared to the sheer scale of Node.js, Angular, React, and JS downloads from npm and GitHub, this is relatively small.

JavaFX simply does not have the user base of HTML5/JavaScript. A business needs support, as well as readily-available developers well versed in a chosen technology. Silverlight, and Flex (outside of Adobe), are dead. Remember the death knell from Adobe as they handed Flex over to the Apache Software Foundation ...

"(HTML5 is) the best technology for enterprise application development."

The Alternatives

Say "web application" today, and the immediate thought is React, Angular, Vue or perhaps another lightweight library like Preact. Native mobile is overwhelmingly Android (Java) or iOS (Swift/Objective-C). "Single" codebase native translates to React Native or Flutter. Progressive Web Apps (PWAs) have taken strides to provide a native-like experience over multiple platforms, and can also be achieved with some of these frameworks/libraries. We are also seeing the rise of lighting-fast static site generators like GatsbyJS combining approaches to great effect.

The crossover effect of the PWA: web applications made "desktop viable" should not be underestimated. Integrating an application with the desktop, sitting an icon on the homepage for mobile/tablet has some serious advantages:

  • They have a reduced footprint. Compare Twitter native to Twitter Lite for example.
  • PWA run as both web application or native application.
  • They work offline.
  • Loading time improves markedly. They can even potentially always be running in memory.
  • Desktop applications gain visibility and improved accessibility.
  • Notifications are available. Ubiquitous in modern applications; used wisely, these can be key in maintaining fluid, habitual user-interaction.
  • Auto-update is enabled.
  • Potentially one team required to maintain, rather than separate mobile/desktop specialists.

Another option is to keep the desktop alive via the web with something like Electron, or Vaadin. This hybrid approach of wrapping web applications inside native applications has a number of benefits. In fact, this also allows for a web-desktop installable PWA, with even vendors like Microsoft, store-enabling them to be rolled out to the desktop alongside native applications.

Weighing Up

We live in a world that has moved to the web. Even Vaadin, while fighting to keep desktop alive, requires a local server when running in client-mode. If your business has hiring, support, and future proofing in mind, and is not restricted to the desktop, it's very likely that a web application is the way to go. You're going to be ensuring that JavaScript is your team's learning priority before choosing your library/framework, and investigating PWA's.

If your organisation has existing Swing/JavaFX applications, and you're confined to the desktop, it would be wise to be aware of Oracle's future direction for Java SE, heeding those changes to deployment in Java SE 11.

If you're building a complex GUI similar to the Deep Space Trajectory Explorer or PAMGuard, then either JavaFX or a JavaScript library/framework can handle that proposition.

I can't help but feel that JavaScript has matured. Important aspects like tooling (VSCode, WebStorm), testing (Jasmine, Jest, Mocha), and enterprise backing (Facebook, Google, Microsoft, Netflix, PayPal) are in place. It may still be ugly, but it's gradually becoming less so. I'm prepared to gamble that the likes of React and Angular will still be ticking along nicely in 2029.


Currere's range of Java courses can take you from beginner to competent Java developer quickly and effectively. We use Swing for learning object-oriented programming, and cover the basics of JavaFX. If you choose the web route, we also have comprehensive React and Angular course. Find more information on our training pages, or get in touch for help achieving your learning goals.