HTML and Java APIs

We caught up with innovator Anton Epple to learn more about the new links between HTML and Java and about what he is looking forward to at the annual JavaOne conference.

JAXenter: You have created an entirely new kind of synergy between HTML and Java. Can you tell us a bit about it?

Anton Epple: Two years ago I noticed that JavaScript is on the rise and even Java programmers are forced to use it if they want to execute some code in the browser on the client side. For me, JavaScript is just another assembly language. People should not use it directly, like they don’t use x86 instruction set directly anymore. It is fine to write in some real language and generate JavaScript, but coding JavaScript directly just make no sense. It is a language for simple scripting.

Anything larger written in JavaScript soon becomes WONTA: write once, never touch again. As such I started to explore what it would take to replace JavaScript with Java, but still keep HTML. Many JavaEE frameworks try to hide JavaScript as well, but I was more interested in pure client, a server-less application. Something like Cordova, but without the need to code in JavaScript.

How did you create the API?

Java is known for its verbosity compared to other languages. One goal that I set for myself was to create an API that would result in programs in Java that are shorter than comparable programs in JavaScript. It was not easy, but I believe I know everything about API design in Java (I even wrote few books about the topic) so I harnessed the most power tool that Java API designer has: annotation processors. At the end I believe I achieved the goal. Application written using the HTML/Java API are usually shorter than original JavaScript or Dart based examples.

One thing I needed to avoid was the verbosity of classical JavaBean pattern and its getters and setters. I managed to do it with the @Model annotation. One just defines the Properties and their types and the whole JavaBean class is generated during compilation. Initially this may feel a bit upside-down, but people get used to it and find it productive. By the way, there has been some attempts to do this before (project Lombok comes to mind), but my solution needs no hacks. It is 100% valid Java code which gets compiled by standard Javac. The other issue was to effectively represent an HTML page and make it “live”.

There were few options, but my favorite is based on knockout.js which is one of the four most popular JavaScript libraries. It allows to annotate HTML elements with a binding to a model (see their excellent documentation) and whenever the model changes, update the DOM tree accordingly.

Of course knockout expects model in JavaScript, so my main task was to make sure one can write that in Java and the rest is generated. Again I used the @Model annotation for that. Btw. the implementation is not Knockout specific – there is an SPI to plug in the Java/JavaScript bridge – as a result people can implement bindings for their favorite technologies.

At present I am aware of bindings for controls.js – a promising touch-ready set of powerful HTML widgets, so people can use those in their Java app instead of HTML with knockout bindings. These two cases make me believe that integrating other binding technologies like angular.js (another popular JavaScript framework) should be possible. The last kind of operation that almost every JavaScript application does is working with JSON – sending data to a server and obtaining a reply in usually asynchronous way.

The classical approach requires some callback interface, but I decided to tackle the issue with yet another annotation: @OnReceive. 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.

You claim it’s possible to deploy these applications everywhere?

True. While the HTML/Java API has been primarily designed for NetBeans purposes, it has been created to be as “lightweight” as possible – it has as little runtime dependencies as possible – it does not depend on any other libraries (rather it exposes SPI to allow different implementations) and as such it does not require full featured Java SE to be executed – it can run on alternative Java virtual machines. Even those that support just a subset of what is now called Java.

My minesweeper game, which I use as a simple example, is available at AppStore, Google Play, as a module for NetBeans and also runs directly in a browser.

Really everywhere?

Really. All you need is ability to execute Java code and display HTML. Of course it does not mean your current Swing based application will run everywhere, but if you create your application using the HTML/Java Maven archetype or appropriate NetBeans IDE wizard and evolve it with portability in mind, you can be sure it runs everywhere. First of all we can use JavaFX’s web view to run on desktop.

It is very useful for debugging (both Java as well as DOM structure) and for fast development of your application. Once ready you can publish the application as a standalone JAR or embed it into existing JavaFX (and thus also Swing) application. This is the way we use HTML/Java in NetBeans right now and the way I’d like to integrate HTML/Java into Eclipse.

Mobile or browser?

Android is easy. There is the Dalvik VM which can execute Java code and there is the WebView widget which can display HTML. It is “just” necessary to connect them. Well, saying “just” is a slight overstatement as it took me many sleepless nights to do it: the communication between Java and web view is asynchronous on Android and especially recursive calls get tricky. But now it is ready and thanks to HTML/Java TCK (which contains more than hundred tests) we know it behaves the same as on other systems. I thought iOS would be a challenge, but thanks to RoboVM project it was not that hard. RoboVM takes Java bytecode and converts it into LVVM assembler code – the same assembler that Objective-C targets – as a result the same, native code is produced, but one can code in Java, no need to suffer with Objective-C.

In addition to that RoboVM provides bindings to native iOS widgets including WebView component. It was “just” necessary to bind Java and JavaScript. This time it was way easier, as the calls to web view are synchronous on iOS and return a result value. Then we have the browsers. Displaying HTML is of course easy, we are surrounded by an HTML page. But how should we execute Java? Java plugin is being banned by Firefox and Chrome and anyway it feels a bit heavyweight. Let’s write virtual machine that takes bytecode and generates JavaScript! That’s actually where I started: I wrote my own VM called Bck2Brwsr. Two years ago, just after JavaOne I managed to execute my first application in an HTML page – a simple calculator.

How is this possible?

The virtual machine takes bytecode and translates each instruction into a JavaScript snippet. The translation usually happens ahead-of-time, when building on desktop, but the Bck2Brwsr VM handles just-in-time compilation as well (yes, one can load JAR files and their classes directly in the browser). The whole approach has its limitations (for example no threads), but the VM is sufficient to execute HTML/Java apps.

When I talk about my Bck2Brwsr VM people often think it is a crazy idea. Possibly, but writing a JVM is not hard (the bigger problem is to implement libraries) and moreover I am not the only one trying that. I was contacted by Alexey Andreev who writes his own TeaVM. He was kind enough to put in necessary hooks for HTML/Java API support and as a result the minesweeper game can also be executed on his VM. I believe this is a great example how portable the HTML/Java APIs are.

So does this mean Dart has just become obsolete for Java programmers?

I would say so. Last Friday there was a JavaDay conference in Wien, Austria. It started with a talk about Dart and Angular (Java conference!) and the audience was quite impressed by the ability to write single page HTML application in a language that looks like a language and not just another assembler (like JavaScript). I could feel them thinking: “Should I learn Dart to be able to do such cool things?”.

So I borrowed the HTML & Dart sources and in the next three hours I rewrote them to HTML/Java. When it was my turn I could stand up in front of the audience and tell them: “hey, you don’t have to learn Dart, stick with Java, use HTML/Java APIs and Knockout bindings and you can do this too!” I think I attracted a bit of attention and got some applause.

What talks are you looking forward most at this year’s JavaOne?

I have to admit, I don’t know. I am so busy with my own talks and demos that I have not had time to look at the schedule yet. I just want to meet interesting people and have a great time. Meanwhile I will talk about API Design [Tuesday Sep 30, 12:30 – 13:30, Hilton – Imperial Ballroom A] which is usually a topic that attracts attention. I convinced Niklas Therning from RoboVM to do a BOF about alternative virtual machines [Monday Sep 29, 19:00 – 19:45, Moscone South – 305] and I am really looking forward to it: I envision two geeks, hands in computers answering questions like: “how did you implemented weak references, threads, classloading, binding to native methods, etc.” and showing the VM internals.

Then, of course there is HTML/Java and surrounding ecosystem named by Toni Epple “DukeScript”. Toni will have a talk[Monday Sep 29, 14:30-15:30 Hilton Golden Gate 4/5] and we’ll do a tutorial[Tuesday Sep 30, 8:30 – 10:30: Hilton – Plaza A] as well. I am a bit nervous about it – I know the HTML/Java technology has a great potential, but I am not sure whether it attracts enough attention.