Common Misconceptions about DukeScript

DukeScript is a relatively new Technology. As such it suffers from some misconceptions. I recently found a thread on Reddit discussing wether DukeScript could “take off in popularity”. Well, we definitely think it should and are prepared to deal with it, but some of the people on this Thread didn’t think so. I’d like to answer the questions and misconceptions here, because it might also help readers of this Blog to avoid these mistakes:

"As far as I can see it's just a GWT clone."

That’s a very common misconception. But it’s wrong. GWT is by definition a web toolkit. You can use it for writing web applications. You write Java, and it’s compiled to JavaScript. Then it’s typically deployed to a server and you run it in a browser.

DukeScript’s is pure client technology: You write your application and it’s business logic in Java which is compiled to Java bytecode. The bytecode is running in a normal JVM. If you deploy the application to the Desktop, the JVM is HotSpot, and you deploy an executable, e.g. an exe on Windows.

If you deploy to Android, it’s an Android application package (APK) and the JVM it uses is Dalvik, and if you deploy to iOS the deployment format is an .IPA and the JVM it uses is RoboVM.

One of the reasons for the misconception is that we also make use of HTML. We use it to define the View. We then use a Java component that is capable to render HTML to display the view.

The second reason for the misconception: We also support running our application in the browser. For that we use a JVM that runs in the browser, for example TeaVM or bck2brwsr. That part is actually similar to GWT, because now an application written in Java runs in a Browser. Even though the code runs in an actual JVM, under the hood there is JavaScript. But this is only a small part of DukeScript, and actually the most experimental one. And although we’re proud to have our own version of applets that can run without a Java Plugin, we don’t see DukeScript as competing with a Web Toolkit.

We rather compete with Swing, GWT, and JavaFX, allowing Java Developers to deploy their client application to iOS, Android, and with some restrictions also to the browser.

"How is it not like GWT? It compiles Java to JS."

The whole Thread focuses on the bck2brwsr part. It’s probably our own fault that bck2brwsr and DukeScript are commonly mixed up. Admittedly we also find it very interesting to run Java applications in a browser, although it’s not our main focus. So again, bck2brwsr is only a minor, experimental part of the DukeScript story.

But even if we take it as a statement about bck2brwsr it’s wrong. One guy on this thread, a GWT developer, answers this question really well:

“The Bck2Brwsr project which DukeScript relies on takes compiled Byte Code and either pre-converts it to JS or does a JIT conversion to JS with a JVM implemented in JS. GWT instead takes Java Source and compiles it to JS. Its a different model.”

As a result bck2brwsr can take an unaltered JAR, for example a Java library like jbox2d and use it directly as a dependency.

"You seem to not have access to the JS ecosystem"

Now that’s actually totally wrong. You can use any JavaScript library available. The main goal of DukeScript is to make it easy to use the wide ecosystem of JavaScript libraries. There are two ways of doing it, one for the view part only, and one for the Java code:

If it’s for the view part only, just reference the JavaScript library in the HTML as usual and use it in the View. That’s it. One example would be if you want to use Twitter Bootstrap, the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. It just works without any changes.

In a more complex scenario you might want to talk to JavaScript libraries from the Java Code, you can define the JavaScript library as a @JavaScriptResource. Then you can use the JavaScriptBody Annotation to provide a typesafe way to call it’s JavaScript functions from Java. Here’s a simple online example of this annotation.

As a GWT developer you might find this concept familiar. @JavaScriptBody is inspired by GWT’s JSNI - there even is an automatic conversion tool to convert JSNI to @JSB.

Two more complex example are the (Canvas API)[https://github.com/eppleton/canvas] and the Leaflet API. They provide a complete Java API for HTML 5 Canvas and the Leaflet Map component.

So DukeScript makes it really simple to use a JavaScript on every level, from using it in the view only to providing a full blown typesafe Java API.

"I'd suspect a lot of the Java ecosystem is closed off also"

That’s also wrong. Restrictions depend on the deployment platform. If you deploy to desktop you’ve got access to every Java API available. If you deploy to iOS and Android You can use the subset of Java APIs available for Android. Only if you wouldlike to use our experimental support for running in the Browser via bck2brwsr, you are limited to a small subset of all available Java APIs.

"It also looks like it has no RPC framework"

The application and it’s logic is mainly running on the client, but if we need to talk to the server we try to make it as easy as possible by using annotations. With the @OnReceive Annotation you can define a JSON communication endpoint in your view model. Here’s a simple example of how to get a Person object from the server:

@Function
static void requestSmith(MyModel m) {
   m.getANewPerson("http", "Smith");
}

@OnReceive(url = "{protocol}://your.server.com/person/{name}")
   static void getANewPerson(MyModel m, Person p) {
     System.out.println("Adding " + p.getFullName() + '!');
     m.getPeople().add(p);
   }

DukeScript ViewModel classes natively support JSON and like GWT-RPC we can serialize and deserialize any view model Object to and from JSON. The NetBeans support for DukeScript ships with a sample application that contains a server and a client. You’ll be surprised how simple it is to setup the communication, and if your backend is written in Java, you can even reuse the model classes on client and server.

In summary, it seems that most misconceptions are due to our support for deployment to the browser. And though our support for bck2brwsrs is only a small -and the most experimental- part, it’s commonly mistaken to be the core of DukeScript. I hope i managed to clarify this and help interested developers to get a clear picture of the core idea behind DukeScript:

Making it possible to run Java applications everywhere with the latest view technologies from HTML5 and JavaScript.