WebView, the other JavaFX UI

Aside from its native UI facilities, JavaFX provides a WebView that’s essentially an embedded HTML5 browser. The underlying WebEngine is a modified Webkit engine which you can download here. Digging through the source code, JavaFX 2.2.4 uses Webkit version 535.21 – nearly two years old by now, according to the Webkit version tracker. Still, the current 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:

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); // JDK 8

        primaryStage.setTitle("HTML Chess");
        primaryStage.setScene(new javafx.scene.Scene(root, 1100, 1000));
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

There’s just one tricky part: WebEngine.load() requires absolute file paths. 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):

HTML Chess

HTML Chess (click for original size)

You may notice that the text is too small compared to the window title. That’s because WebView currently only supports text zoom, not full page zoom, so I cannot properly upscale the HTML content for my 150% DPI setting. Luckily the upcoming JDK 8 will add a zoom property that should allow full DPI compensation. Looking at the early access code, JDK 8 should also try to load relative file paths from the current user’s home directory.

JavaFX supports fairly 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, and let JavaScript functions call back to arbitrary Java methods. 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 with the new JDK 8 zoom property should provide better high DPI support than native JavaFX controls…
  • 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.

2014-01-12: Turns out Intel had a similar idea back in 2011 and created the free node-webkit, a multi-platform runtime that packages Chromium with node.js for pure client-side execution of HTML5 applications. Also see this tutorial.

2014-01-18: Sanjeev Radhakrishnan’s Chrome Is The New C Runtime proposes using Chromium as a fundamental library for native C++ development. He wants to build native GUIs and mostly use Chromium for networking, but it should be simple to create a cross-platform HTML5 UI in Chromium instead.

2014-03-01: GitHub’s Atom editor calls itself “web native.” The editor is written in HTML/JS and dynamically updated, but executes in a native Chromium application in order to get around JavaScript’s security restrictions and browser compatibility issues.

3 thoughts on “WebView, the other JavaFX UI

  1. fraggle

    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 :(

    Reply
    1. Christoph Nahr Post author

      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.

      Reply
  2. Pingback: openJSDE, my HTML5 Desktop framework [14.04.2014] | GameplayJDK's Blog

Leave a Reply