Geertjan's Blog

  • April 17, 2015

Java in the Trenches

Geertjan Wielenga
Product Manager

Java has been driven into the trenches, some years ago already. (Slightly under hundred years after the photo on the left was taken, in 1914.)

More or less the general consensus appears to be that the frontend battle has been won by JavaScript.

So, what's the role for Java in this brave new world? More or less the general consensus appears to be that Java has great value on the backend. The Java EE Platform is awesome in that it consists of specifications agreed upon across the industry, whereas the JavaScript ecosystem is crazy mad cowboy land.

However, what happens when those frontend developers, who have, without any resistance, moved to JavaScript, discover the value of Node.js over the value of the Java EE Platform? What happens when they see the value of doing the frontend and the backend in the same language, i.e., JavaScript? What happens when they rate that value higher than the value of the industry-based specification-approach promised by the Java EE Platform? When the value of an agreed upon industry-wide platform, i.e., the Java EE Platform, weighs less than the value of having a common programming model right across the application, from its front to its back... then what happens? Java will have no place in the browser and will be pushed back further still, into the purely scientific world, focused narrowly on simulation software, relevant to back-office banking and defense force software, that is, desktop solutions and console solutions, only, where the NetBeans Platform is the purest Java solution, in terms of application framework. It will then be competing with Cobol and AS/400 RPG and their various other crusty friends. 

It's hard, but let's be honest. 

What is to be done? Instead of giving up on the frontend and retreating to the backend, from which a further retreat will inevitably follow, into obscurity, the frontend should be defended, simply because the Java ecosystem is so much better than the JavaScript ecosystem, as Java developers know, by Java developers. How? By means of DukeScript.

Join the discussion

Comments ( 25 )
  • Emilian Bold Saturday, April 18, 2015

    You are forgetting about the mobile front end which is the only front end most people see.

    And with Android, Java the language still has the front-end, except it’s with a runtime and UI toolkit made by Google.

  • Jaroslav Tulach Saturday, April 18, 2015

    Right Emillian, Android is de-facto synonym for "client side Java" these days. Without Android the usage of Java on client would be limited to desktop apps - e.g. legacy banking and defense software - and would be even lower.

    However real Java "write once, run anywhere" story needs to provide sufficient answer to question: "How to deploy your Java application to not only Android, but also iOS, desktop and browsers as well?"

    Toni's DukeScript has a viable story for all these devices and that is why I am huge supporter of DukeScript.

  • Geertjan Saturday, April 18, 2015

    Emilian, watch these new YouTube clips by Jaroslav Tulach, done yesterday, explaining his vision in some detail. Part 1: https://www.youtube.com/watch?v=IDo1NrKsyiY Part 2: https://www.youtube.com/watch?v=GNYixf_6SKQ

  • guest Saturday, April 18, 2015

    We should concentrate firepower support Robovm

  • guest Saturday, April 18, 2015

    It is unconscionable for me to even think of my internal users trying to get their work done in something as crude as a browser interface!

  • Geertjan Saturday, April 18, 2015

    No one says that you have to use a browser interface with DukeScript... that's precisely the point of DukeScript: you can choose which type of device you want to support (desktop or browser or mobile or whatever). However, you're always able to scale out to any other device, whenever you want.

  • guest Sunday, April 19, 2015

    Thanks for the history Now I am studying the use of Java. Would have led to a report history teachers.

  • Jaroslav Tulach Sunday, April 19, 2015

    Re. RoboVM. I am huge supporter of Niklas and his team work. Actually, when you deploy DukeScript app to iOS, it is going to use RoboVM. Think of DukeScript as a portable cross-platform user interface for RoboVM!

  • JMB Friday, April 24, 2015

    And what about JFX? Really great for Rich client side applications. And even though a lot of apps can be "web" driven, there are still a lot running on our computers that are not web based (IDE, Text and Image editors etc). For such "native" apps, it is still useful to have a Java technology allows to build those apps such as JFX. Here modern features and seamless integration in the target OS is the key. Swing has somehow lost this battle.

  • Geertjan Friday, April 24, 2015

    I'd say Swing is still dominant on the desktop, over JavaFX, in the area of large software systems that need to be modular, pluggable, and flexible -- because JavaFX doesn't provide any solutions at all for these typical desktop concerns, while the Swing-based NetBeans Platform does so, very well: https://platform.netbeans.org/screenshots.html

  • JMB Friday, April 24, 2015

    I fully agree. I am just a bit annoyed when I see "legacy software". We are still creating modern desktop apps. But, still, Swing is no longer maintained and it is time to replace it by something more modern. I like the new features in JFX and I am just waiting for the graal: NBP on JFX or the other way round ;). I am also dreaming about running such apps on mobile devices. I know there are solutions, but a better support from Oracle would be greatly welcome.

  • Geertjan Friday, April 24, 2015

    I think Swing is great and it's perfect for what it does. However, the DukeScript project is really interesting, take a look at it, spend some time with it. One of the outputs of a DukeScript application is JavaFX. I.e., JavaFX is generated from the HTML/Java code that you write, as well as an Android app, an iOS app, and a web app. All automatically, when you compile the project.

  • Toni Epple Friday, April 24, 2015

    @guest: DukeScript is using RoboVM for iOS

  • JMB Friday, April 24, 2015

    I'll have a look at it. But still, when we need to start a new project, our management wants to know the "support" of the technologies we are going to use. Young ones are not welcome, except if Oracle is officially supporting them, which is the case of Swing and JFX...

  • Geertjan Friday, April 24, 2015

    DukeScript is supported by Eppleton IT Consulting: https://dukescript.com/index.html#contact

  • Toni Epple Friday, April 24, 2015

    The idea behind DukeScript is simple:

    - Almost any platform can run Java. There's RoboVM on iOS, Android supports it natively, desktop has Hotspot, even Browsers supprt it via bck2brwsr. The thing that is missing is a unified Java UI toolkit that works on all of them.

    - Almost any platform has a HTML-renderer component. Android has WebView, ioS has UIWebView...

    Why not use these components as a unified UI Toolkit for Java? It "only" requires a thin platform-specific layer for synchronizing the View with the ViewModel. And as a result we have "Write Once Run Anywhere" again.

    That's DukeScript.

  • JMB Friday, April 24, 2015

    Great that Toni is supporting it.

  • Toni Epple Friday, April 24, 2015

    @JMB : You are welcome to contact me about details on supporters and support options.

  • guest Friday, April 24, 2015

    "What about JFX?" - JavaFX is dead.

    I am not Oracle employee, but I couldn't notice that the amount of people working on JavaFX is decreasing and decreasing. That is a problem - JavaFX is full stack - from the designer, via the Java APIs, through various rendering pipeline implementations down to the hardware accelerator of your graphics card. That is a lot of code to maintain and write when porting to new platform.

    It is fine you can buy support for it, but unless the situation rapidly changes, you won't get new features - at most trivial bugfixes.

    The situation with DukeScript is quite different: it reuses Java virtual machines that are already written and recognized as industry standard. It reuses HTML rendering pipelines which every platform/operating system provider has to maintain anyway. It just adds small, yet inventive binding between these two elements and ensures it works the same on all the supported platforms. As far as I can tell, this can be maintained with incomparably less efforts than JavaFX and it is close to trivial to support the latest developments in the area of Java VMs as well as HTML rendering.

    If you want real support for your client-side Java UI technology - I encourage you to contact Toni!

  • JMB Friday, April 24, 2015

    "JavaFX is dead" Is it?

    Is DukeScript a real alternative to create rich and powerfull desktop apps that allows, say, create modern animations (compositing), Swing like components (without hitting a server for every single operation) or even able to create apps with 3D visualizers and designers? What about OS integration? If yes to all those points, then it can become a very interresting replacement for Swing.

    I regret Oracle doesn't clearly state which is the technology that they support and should be used as replacement of Swing... (not only my personal understanding of the situation)

  • Geertjan Friday, April 24, 2015

    Anything you can do with HTML you can do in DukeScript -- can you create modern animations in HTML, can you 3d visualizers in HTML, etc etc. DukeScript is simply a framework that combines the JVM with the browser, on all platforms and devices. Personally, I don't believe either Swing or JavaFX are dead -- I believe they're stable and they serve their purpose. If JavaFX fits your needs, use JavaFX, if it's Swing use Swing, if it's both, use both, if your front-end needs can be expressed in HTML and you don't want to use JavaScript, use DukeScript.

  • Jiri Tulach Friday, April 24, 2015


    Even though we are fighting on JavaScript battle field we also work with DukeScript. The HTML UI can be pretty close to Swing components. So close that user is not able to distinguish between Swing UI and HTML UI. I also don't think the HTML UI is Swing or JavaFX replacement but can be an option to create and run same UI on all platforms and devices. With our technology Java developers don't need to write a single line of HTML or JavaScript and still are able to create rich and powerful applications that runs (almost) everywhere.

    Jiri Tulach


  • Toni Epple Saturday, April 25, 2015


    > create modern animations (compositing)

    Yes, you can create modern animations with it. The suggested way is via CSS3 if we're talking about business applications. It's miles aead of what you can do with Swing, and it's much better than JavaFX, which doesn't have a way to do declarative animations (It was planned, but never happened like so many things ). If you need more there's a Canvas API, with which you can do immediate mode rendering. This will allow you to create graphically rich applications (games...). Still, if you want to write video editing software, or a first person shooter I think neither Swing, nor JavaFX nor DukeScript are the right technology.

    > create apps with 3D visualizers and designers

    Sure, DukeScript is optimized for creating Java APIs over JavaScript. Writing an API for WebGL would be an afternoon. But again, if you want to create a really complex 3D-Designer, neither Swing, nor JavaFX nor DukeScript are the right technology.

    > Swing like components (without hitting a server for every single operation)

    DukeScript is pure client technology, no server involved.

    > What about OS integration?

    DukeScript Apps are native apps. If you want to access something device specific you can do that. It just requires a bit more effort than using the cross platform APIs. The good thing is, that on mobile platforms there are simple ways to access device APIs. E.g. RoboVM, which is used on iOS allows you to access all the iOS APIs via Java, and on Android it's natively in Java anyway. On Desktop it's exactly the same as with Swing: You can use native APIs, but it requires you to write some JNI unless there's already a Java API for it.

    So a clear yes to all.

  • JMB Monday, April 27, 2015

    Great. I spend many years on HTML and webapps in my past. I don't really want to go back there (I don't like the Javascript language) and in our business, that is not a great platform (yet?). So DukeScript definitely deserves a good look.

  • guest Tuesday, October 6, 2015

    why not create a portable browser that can run native Java and JavaFx code, make it free like Firefox and Chrome and give it built-in developer tool capabilities mimicking Netbeans? I'm sure a lot of people would love that.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.