Aside from its native UI facilities, JavaFX provides a WebView that’s a fully-featured embedded HTML5 browser. The underlying WebEngine is a modified Webkit engine which comes as part of the freely available JavaFX source code.
- For JavaFX 2.2.4 (part of Java SE 7), Oracle offered a separate download. This code was based on Webkit 535.21, released on 17 February 2012.
- For JavaFX 8 (part of Java SE 8), Oracle did not update this download but you can grab the entire OpenJFX source (42.4 MB for the BZ2 package). The included
WebEngine
is based on Webkit 537.44, released on 6 June 2013. - For Java SE 8 Update 40, released in March 2015, the corresponding OpenJFX source (46.3 MB for the BZ2 package) still contains Webkit 537.44 with some minor changes.
- For Java SE 8 Update 60, released in August 2015, the corresponding OpenJFX source (60.2 MB for the BZ2 package) was updated to Webkit 538.19, released on 19 February 2014.
The Webkit release dates are available in the Webkit version tracker. The Webkit version information can be found in the following file within the OpenJFX source package:
modules/web/src/main/native/Source/WebCore/Configurations/Version.xcconfig
For Java SE 8u40, only 1% of the files in the WebCore
directory tree were changed, with minor bug fixes as far as I can tell. On the JavaFX mailing list, maintainer Kevin Rushforth stated that the delay is due to WebKit switching to C++ 11, triggering laborious tooling changes in the JavaFX compilation chain. Java SE 9 should receive updated versions more frequently.
Sample Application
WebView
could run all the HTML5 sample applications I threw at it. The one I’d like to showcase here is HTML5 Chess, a terrific open source project by Stefano Gioffré. Although sadly abandoned today, the final release is a complete working chess program written in HTML and JavaScript.
You can play the demo online but for WebView
hosting you should download the latest version. Extract the htmlchess
folder from the archive, and then run this tiny JavaFX application from the directory that contains htmlchess
:
package org.kynosarges;
public class WebViewTest extends javafx.application.Application {
@Override
public void start(javafx.stage.Stage primaryStage) {
// path in current directory for WebEngine.load()
final String html = "htmlchess/example.html";
final java.net.URI uri = java.nio.file.Paths.get(html).toAbsolutePath().toUri();
// create WebView with specified local content
final javafx.scene.web.WebView root = new javafx.scene.web.WebView();
root.getEngine().load(uri.toString());
root.setZoom(javafx.stage.Screen.getPrimary().getDpi() / 96);
primaryStage.setTitle("HTML Chess");
primaryStage.setScene(new javafx.scene.Scene(root, 1100, 820));
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
There’s just one tricky part: WebEngine.load()
requires absolute file paths, marked with the URI prefix file://
. We want to load from a relative location, namely the current directory, so we need to fix up the location using Path
and URI
. If you’re running from within NetBeans, note that the current directory is the one above the dist
folder containing the JAR file. Run your executable JAR and you should see the following window (after clicking “Both” to show both the 2D and 3D chessboard):
The screenshot was taken at 100% DPI scaling since the page has a lot of content – the Portable Game Notation (PGN) reader below the lower window border is not even visible! As of JavaFX 8 WebView
supports full page zooming which the sample code matches to the current system DPI setting. A text-only zoom function is also available, though not terribly useful.
WebView Advantages
JavaFX supports rich interactions between the Java application and its hosted WebView
. You can access the HTML document through the usual Java org.w3c.dom
API, attach Java handlers to selected JavaScript events, use executeScript to run arbitrary JavaScript code snippets, and let JavaScript functions call back to arbitrary Java methods.
Regarding HTML5 capabilities, JavaFX 8 added web sockets, web workers, and web fonts, along with printing HTML pages. Of course WebView
can simply show remote websites or local help pages, but there are a few reasons to consider moving your main UI into WebView
:
- Tragically,
WebView
page zoom offers better high DPI support than native JavaFX controls since JavaFX still doesn’t scale drawing coordinates… (2015-07-03: finally fixed in Java 8u60) - Create two-tiered cross-platform applications, with a common baseline written in HTML/JS that runs everywhere, and extra features provided via embedded JavaFX deployment where possible.
- Run HTML5 apps on desktop systems that lack a sufficiently compatible web browser. You actually don’t need an installed modern JVM either, as the JVM is perfectly capable of private deployment. This can be automated with JavaFX native packaging.
- If you share the growing consensus that HTML/JS is the future of client-side programming, get ready for that future by targeting
WebView
, supplemented by Java(FX) for the parts where HTML is still lacking or JavaScript is too slow.
In the HTML Chess example, some obvious improvements would be better management of local PGN files, or an alternative Java implementation for the slow JavaScript turn prediction (enabled by “Machine Meditation Level”). The idea of a JavaFX client application with an HTML UI might seem weird at first, but I think it’s an interesting option – and probably a necessary one, given the rapid spread of HTML/JS as a standard UI technology.
Java DukeScript
As of April 2015, Anton Epple’s DukeScript seems to emerge as the principal framework to build cross-platform Java UIs based on HTML and JavaScript. DukeScript uses Knockout.js to connect Java classes with the HTML frontend. The latter is presented by the JavaFX WebView
on desktop systems, by the native WebView
on Android, and by the RoboVM UIWebView
on iOS (see current source code).
NetBeans’ Geertjan Wielenga has long been championing DukeScript, most recently in Java in the Trenches where he argues that Java must provide a viable frontend option based on HTML/JS: More or less the general consensus appears to be that the frontend battle has been won by JavaScript.
Naturally there’s a NetBeans plugin for DukeScript already. It will be interesting to see if the framework takes off, or if Java developers are content to continue their slide towards “Cobol and AS/400 RPG and their various other crusty friends,” as Wielenga puts it.
Other Projects
After posting this article I discovered a number of related projects on the web, both old and new. It seems the concept of combining local applications with browser engines is gaining traction. This section, last updated on 26 March 2016, collects links with brief introductions to such projects.
- Intel created the free NW.js (node-webkit), a multi-platform runtime that packages Chromium with node.js for pure client-side execution of HTML5 applications. Maciej Sopyło and Paul Jensen wrote extensive tutorials for this process.
- GitHub’s Electron is a popular alternative to NW.js that was originally created for the Atom editor. Jensen’s tutorial covers Electron as well as NW.js.
- Apache Cordova (née PhoneGap) allows deployment of HTML/JS applications to mobile app stores using native wrappers. Supported platforms include iOS, Android, and Windows (including Universal Windows Apps). Microsoft provides Visual Studio Tools for Cordova.
Hey, i stumbled upon your article while searching for a solution to “fix” the high dpi “issue” on javafx webview. I just wanted to ask, if you maybe found some workaround or anything else to get rid of wrong dpi compensation on webview? At the moment i’m developing a standalone program where i need the webview for displaying a rich html editor which scales really bad on small screens with high resolutions&dpi :(
You can try changing the fontScale property, but if that breaks the layout you’ll have to wait for Java 8 (or use the developer preview) with the new zoom property, as shown in my code sample. I don’t think there’s another workaround at this time, sorry.
i agree with the possibility of using HTML5 as front-end and using java as backend, HTML5 is a UI monster optimized for mobile/touch/responsive experience, with the javaFX android/IOS ports a single component webview opens a lot of new opportunities, i have seen javascript call back/up with javaFX code, while javaFX for mobile is still under construction i might as well take the HTML5/WebKit UI advantage first
I’m just discovering this now as we grapple with the need for offline web forms and data privacy concerns. We wanted to use embedded Jetty but opening up ports on the client machine is a scary prospect when you’re releasing professional software to business partners. Does NW get around this somehow using some sort of runtime based pipeline for http(like?) comms?
Hey Christoph Nahr,
We are building a finance application (Native). We are in the process of choosing between JavaFX controls vs JavaFX+HTML5. We would need support for printer and keyboard shortcuts. Do you think its a good idea to use HTML5 for making all the views? Any disadvantages you can think of?