Jaroslav Tulach, NetBeans Founder and Initial Architect, and Anton (Toni) Epple, a Java Consultant and Trainer, have recently won a 2014 Duke's Choice Award with DukeScript, a technology meant to bring Java to every client, mobile or desktop, without the need of a plug-in. In spite of its misleading name, DukeScript is not a new scripting language but an attempt to “put Java back in JavaScript”, in an attempt to fulfill the initial vision for Java: Write Once, Run Everywhere.
DukeScript is a technology for creating cross-platform mobile and desktop applications with Java and HTML5. Unlike other solutions which make use of Java on the server side, DukeScript uses Java on the client side without relying on Oracle’s plug-in used in the past to run applets. The technology runs on Android, iOS, desktop browsers, and any HTML5/JavaScript environment.
Epple explained to InfoQ how DukeScript and related technologies work:
The basic architecture of a DukeScript Application is actually very simple and consists of three components. There’s a Java Virtual Machine, there’s a HTML-Renderer Component, and there’s DukeScript. DukeScript glues the JVM and the HTML-Component together and acts as a bridge between the business logic running in the VM and the UI written in HTML/JavaScript.
DukeScript applications run inside a JVM and use the HTML-Renderer to display the page. When the page is loaded, DukeScript binds the dynamic elements of the page to the data model using Knockout.js internally. The difference to a classic Knockout.js application is that the data model consists of Java Objects, which the user can manipulate from his Java code. This way the business logic can be completely written in Java and is cleanly separated from the UI.
On each platform we support, we needed to find a JVM and a WebView component and plug them together. Obviously enabling the communication is where the true difficulties lie, since each of the platforms is slightly different.
There are multiple scenarios covered by this technology. On the desktop, out-of-the-browser, DukeScript uses JavaFX, said Epple:
On the Desktop we have the Hotspot VM and the JavaFX WebView, which can talk to Java. This setup is also best for debugging the application. When running on HotSpot the application can be debugged with breakpoints, expression evaluation and all the other nice features IDEs have. In the WebView NetBeans can inspect the DOM-Tree, show CSS and you can dynamically update the HTML of the page while the application is running.
DukeScript works similarly on the two major mobile platforms but with other VMs and web views, added Epple:
On Android there’s Dalvik as the VM and the android.webkit.WebView for rendering HTML and executing JavaScript. On iOS there’s RoboVM [an AOT compiler producing machine code thorough the LLVM pipeline, Ed.] and the NSObject.UIResponder.UiView.UIWebView. By connecting these basic components we can run the same application on these very different platforms.
On the desktop browser, the Java code needs to be translated into corresponding JavaScript snippets. This can be done ahead-of-time or just-in-time with Bck2Brwsr, a JVM written by Tulach. For the JIT scenario, according to Epple, when the web page is loaded, Bck2Brwsr is loaded and in turn it loads the main Java class of the application and instantiates it, then the Java data model is instantiated and bindings with HTML components are created. When Java code is to be executed, Bck2Brwsr translates it into JavaScript and runs the code on the browser’s engine. Bck2Brwsr is not hardwired into all of this, one being able to replace it with another VM. One such VM that can be used is TeaVM.
On Windows Phone, a solution similar to Android and iOS’ could be used, with Bck2Brwsr as the JVM of choice, but it has not been tested yet and some work might be required.
Bck2Brwsr currently has some limitations, according to Tulach: it does not use reflection and the “goal of this project is not to execute any existing Java library. It is expected that libraries for the new, limited environment need to be specially designed.” There are a number of improvements that Tulach would like to implement in the future, asking for the community’s help:
- Use Closure compiler to generate more compact code
- Per individual libraries - ObfuscatePerLibrary
- Access to multipage via sammy.js or crossroads.js
- Method and field overriding with various modifiers
- More reflection support (e.g. don't throw SecurityException when allowed),
- No private method/field/constructor/class access
- Probably no field access
- May need constructor access
- Debugger of Java (and not JavaScript would be good)
- Performance benchmark Sci2000
- Investigate generating asm.js friendly code
- Generate Java wrappers for all HTML5 elements dynamically (Honza)
Another important component of this framework is the HTML APIs via Java 1.0 API (HTML/Java), a package of Java APIs for interacting with HTML pages, initially developed for NetBeans. By default, this API interacts with HTML on the desktop browser via JavaFX WebView, but the API is integrated with Knockout which provides bindings for the data model, so there is no need to directly manipulate the DOM. According to Tulach, the API also works with Controls.js, and support for other frameworks can be added (Angular.js, etc.).
HTML/Java API can be used to make direct calls from Java to JavaScript and back with the JavaScriptBody annotation. One example is the following snippet:
@JavaScriptBody(args = {"x", "y"}, body = "return x + y;")
private static native int sum(int x, int y);
To simplify writing Java code for the browser and avoid the “verbosity of the JavaBeans pattern”, Tulach has used the Model annotation as shown in this sample:
@Model(className="Person", properties={ @Property(name = "firstName", type=String.class), @Property(name = "lastName", type=String.class) @Property(name = "addresses", type=Address.class, array = true) })
The HTML/Java API uses JSON to communicate with a server via HTTP or WebSocket calls, making use of another annotation, @OnReceive. Tulach wrote on this:
It again generates a boiler plate code and as a result transferring data to and from server is a matter of few lines of code. In fact, when comparing the size of original JavaScript samples, this is the area where the new HTML/Java API really excels. The Java code for asynchronous REST or WebSocket communication is way shorter than its JavaScript counter parts.
The HTML/Java API has been designed as “lightweight as possible”, with no dependencies on other libraries, and it can be executed on various JVMs, including HotSpot and Bck2Brwsr.
Epple has extended the HTML/Java library with a HTML5 Canvas API and a Game Engine based on the JavaFX Canvas API.
The DukeScript website showcases several examples, including a simple HTML-Java online editor with an Angular.js To-Do demo.
About the Author
Abel Avram has been involved in many InfoQ editorial activities since 2008, enjoying writing news reports on Mobile, HTML, .NET, Cloud Computing, EA and other topics. If you are interested in submitting a news story or educational articles please contact him at abel [at] infoq.com.