Building cross-platform desktop applications usually means compromising on user experience, ease of development or both. Below I detail the reasoning and trade-offs behind an approach that involves state of the art technologies and development methodology with fewer compromises.
Many organizations have substantial functionality available in the form of Java libraries that they would like to reuse and the corresponding skills, infrastructure and methods to build and maintain application logic in Java. Taking an Electron-like approach to building such applications but with an emphasis on Java for the functional portion of the application could be a good choice in these cases.
Java ships with a WebKit-based WebView for JavaFX. This made a bit of a splash, as previous attempts to embed a browser in Java apps were either using a sub-par Java-based browser, or had crazy dependencies and complex setup.
1. HTML and CSS Tooling
Web developers rely heavily on browser-based tools to develop the look and feel of an application. Modern web browsers provide integrated tooling that provide a way to introspect and modify CSS and HTML. With a couple of clicks, developers can troubleshoot and try out styles and HTML, live in the application. This ability to change an application as it’s running is one of the cornerstones behind web developer productivity.
A JavaFX WebView doesn’t have such tooling. The WebView is a black-box, essentially locking developers out from their most powerful development approach. It’s like going back to the mid ’90s.
One approach to overcoming this limitation is to include Firebug Lite, which enables inspection of HMTL and CSS in almost any browser, including the JavaFX WebView. I did get it working, and though it’s better than not having any tooling, not all versions of Firebug Lite worked for me and I was unable to edit CSS properties live in the application. To be fair, Firebug Lite is not intended as a replacement for Firebug or Chrome development tools. In the end I found that it was insufficient for my needs.
Data type conversion is very limited; most non-trivial use cases will require Java code that introspects
4. WebKit Version
Having a WebKit-based browser ship with the Java platform is great, but which version is it? It appears that updating WebKit on the Java platform is quite a bit of work, since Oracle is not updating the WebKit version very frequently. As of this writing, Java 8 ships with WebKit version 537.44, which is from 2013.
If the embedded WebKit is used as a web browser - that is, to browse the web, not just for your application - then having an up-to-date WebKit is critical for security.
5. Download Size
Distributing a JRE with the application is needed to ensure that the application runs consistently and to keep installation simple (avoiding the need to install a JRE separately). As a result the application size is over 100MB, which could be problematic for some situations.
Mitigating the Drawbacks
With a laundry list of drawbacks our approach of using a JavaFX WebView to host the UI for a desktop Java application is sounding pretty bad so far. But, with a concrete mitigation strategy for each issue, it could be worth exploring further:
Web Development Approach
Web development tooling leverages our team’s expertise and is key to productivity - so how can we come up with a development approach that enables this?
It turns out that we can build a traditional web application by implementing REST services as the interface between our UI and our application. By having the UI call out to REST services, we can have our cake and eat it too.
With this approach our application architecture looks something like this:
In development we can deploy the application as a normal web application like this:
By providing an in-memory HTTP/REST bridge to these services we can run the UI and application logic in one process, while in development we can split the application from the UI by using a web browser and web container. This means that we get the single-process deployment profile of a desktop application, while retaining the web development tools and techniques that we value so much.
To overcome the difficulty of type compatibility and
A major problem for any project is the build system. Maven, Ant, Gradle - whatever you choose, we still need something to build the webby front-end. For this application I chose Grunt with Node, Karma, Jasmine… it’s all there. Ultimately this is the same as any web application using more than one implementation language, there are two build technologies involved, which complicates things significantly.
Web technologies for testing the UI are fairly mature and enable testing on several levels:
- Karma and Jasmine can also be used to test for elements in the DOM.
- Though I haven’t done it here, with use of Selenium WebDriver it’s possible to test application functionality via the UI.
- Using a Java back-end, it’s really simple to use normal unit testing techniques and frameworks, for example with JUnit and Mockito.
Selecting web technologies for the UI makes thorough testing a possibility, covering all aspects of our application architecture.
The only real problem here is that our UI tests will be running using a web browser rather than the JavaFX WebView. It’s hard to say if that’s a major gap or if it’s something that we could live with - I think only experience would shed light in that area.
Migration to Web
If future application deployment as a real web application rather than a desktop application is a consideration, then this approach could be a great way to move forward. The application architecture being a traditional web stack lends itself very well to a web deployment.
A working example of such an application is published on GitHub. I’d love to hear your feedback and thoughts on the application and the approach.
Many, but not all of the development difficulties introduced by running a web application in a JavaFX WebView instead of a standard web browser can be mitigated by supporting a normal web development flow as outlined above.
For me this was a great learning experience and potentially worthy of further exploration. Would I use this as a product development approach for a real application? Maybe, if the trade-offs were to weigh in favour for the needs of the organization and application under consideration. But I’m not completely sold on it - so would keep my eye open for signs of an unhealthy development process and architecture.
- Faster Feedback Loop on Code Reviews
- Surfacing Abstractions in Code Reviews
- Architecting for the Value Stream
- ELK Stack for Improved Support
- Article Index
subscribe via RSS