JavaFXPorts winner of Duke's Choice Award

Yesterday, it was announced that LodgON receives a Duke's Choice Award for its work on JavaFX Ports (http://javafxports.org) and more specifically for the port of JavaFX to Android.

I am a strong believer of Java on Mobile Clients. For a Java developer, the benefits are clear. It makes the Java paradigm "Write Once Run Anywhere" really come true. Write a JavaFX client application once, and use different stylesheets and skins for desktop, iOS and Android. From a strategic point, there are a number of reasons why I think the time is now for Java to increase its market share in mobile client applications.

Mobile Apps are the way forward

First of all, there is a clear move from desktop and laptops towards mobile devices: smartphones and tablets. This is a game changer. Client application on these mobile devices have different requirements than applications on desktop and laptop, which today are mainly web-based.
That brings me to the second reason. Where the browser is the dominant application on desktop and laptops, it doesn't have a leading role on mobile clients. There are a number of statistics about this (e.g. see http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/) and there is also lots of discussion about it.
Many see the failure of the "mobile web" as a threat to the Open Internet. While I understand some of the fears, I rather consider the decline of the mobile web as an opportunity rather than as a threat. Agreed, the tight grip of Apple on the AppStore and of Google on the Play Store might be dangerous. But the browser as the beneficial dictator deciding what can be run and what not is dangerous as well.

Today, Java is a valid choice for Mobile Apps

I don't want to downplay the role of HTML 5, as it is a combination of interesting technologies that still have their place. However, I think the Enterprise World is overreacting by embracing it. The Enterprise World ignored the web for too long, but today we should be looking further.
Many years ago, the Enterprise World was mainly using dedicated fat clients that connected to back-end systems using protocols that were fat, proprietary, or both.
In that time, I didn't like this approach. I still remember I re-wrote a rather complex Java client application in 1999 in JavaScript, so that I could show it to others without having them to install the Java Runtime. It was very frustrating, and it never worked on all browsers at the same time, but I felt there was no other choice than using HTML and the Web. Java wasn't really open, and the process of installing and maintaining Java on the client was cumbersome.
As a side note, it still is cumbersome and embarassing. I feel ashamed when people come to me with their laptop at family parties and ask me what they have to do with all these requests to update "Java". They don't know what Java is, and there is no reason why they should.

Today, there is another choice. Today, the Java Specifications are developed by the rules of the Java Community Process (JCP). Everyone can be an individual member of the JCP. Companies can become member of the JCP. Together, they elect the executive committee, and they can propose JSRs and work on them.
The Reference Implementation for the Java Specification, Standard Edition, is created in the OpenJDK project, which is very transparant as well. Also, today we don't require clients to have the JRE installed. We simply bundle the JRE with our applications. The JavaPackager is a very important and yet underestimated component. I hear worries about filesize now and then, but first of all, the average user today spends a few orders of magnitude more bytes on transfering media than transfering applications. Also, tools can become better, and unneeded modules, packages, classes or methods can be removed from the final application.

There are no technical reasons on why Java and JavaFX on the client should not be considered. So far, I considered my work on JavaFX on Android as a Proof Of Concept. The RoboVM people also showed that Java and JavaFX work on iOS. For LodgON and Trillian, the porting effort is considerable, but when placing this in the right context, it wasn't a huge issue. Granted, the work has just started, and there are lots of things to do, so an increase in resources will be a requirement. But the combined effort shows that it is possible to write Java applications that run on mobile clients as native apps, which is the way forward in the industry.

Mobile apps will influence Enterprise Development

Native mobile apps are not only popular in games or entertainment, but increasingly in business applications as well. While in 1999 I was hoping the Java Enterprise world would embrace the Web, today I hope the Java Enterprise World will pay more attention to Java Clients, and not only to HTML 5. In many products and projects, the added value is often realized in the back-end.  Without providing a vendor or technology lock, Java provides a silver key for this: Java mobile apps can use REST technologies to connect with Java Enterprise rest-based webservices. The JAX-RS spec is therefore extremely important as it defines both the server component as well as the client part of the REST protocol.
Apart from REST, I think there are 2 other very relevant technologies for client-server communication: Server-Sent Event (SSE) and WebSockets. The latter is already covered in the Java Specification as JSR 356 and support for SSE is already part of some REST implementations, including the Jersey Reference Implementation.

One of the other projects I am involved in, DataFX, has a JavaFX component that allows easy interaction between JavaFX Controls and WebServices that either use REST, SSE or WebSockets. I really believe these technologies should be supported as first-class Java components, as part of a strategy for Java on Mobile clients generating traffic to Java on the Server.

Many IT projects today still require a rather complex back-end, often developed using Java EE technologies. Typically, this back-end is made accessiable using an HTML 5 website, and the Java EE specification make it very easy to create HTML 5 based web applications that communicate with a Java EE backend. However, an increasing number of clients also requires mobile clients for Android and iOS. In most cases, native clients are written from scratch for this purpose. That means the total project requires three separate clients, in three languages. That is expensive. But with the growing attention for mobile clients, it might also be dangerous for Java EE. Where the "desktop website" is today in most cases the first client, I think this might change, and the mobile clients will be the preferred clients. It will become tempting for the developers of these apps to use vendor-specific (either from Google or Apple) enterprise cloud services rather than standard protocols that connect to Java EE servers.

In summary, Java on Mobile benefits developers (write your client applications on a desktop and publish them to the AppStore and the Play Store) and it can lead to an increased usage of Java server-side technologies (e.g. cloud services). Time to take it seriously.

written on 29 Sep 2014 15:58.

4 comments

Author: montanajava
Date: 29 Sep 2014 17:30
permalink

Amen, brother! For my company I have reviewed a large number of technology options for mobile. There is a market for classical object-oriented type-safe solutions. That has been proved by Oracle's competitors. If I can stay in the Java world and have a cross-device codebase, at least partially, all the better! What I am not sure that I understand is whether or not making JavaFX run on Android today solves any problems, today at least, if the JavaFX widgets are not adapted to Touch, or if we do not get Touch-enabled widgets, or if we do not wrap native Touch widgets with JavaFX components. Your take would be appreciated.

Author: Johan Vos
Date: 30 Sep 2014 02:25
permalink

@montanajava Thanks for your comment. The JavaFX controls contain support for touch events, and also for gesture support, so that works pretty well on Android. Not sure that addresses your question?

Author: Rakesh Rajput
Date: 09 Oct 2014 18:11
permalink

Respected sir It can possible javafx base application create in windows base platform and that application without any change run on windows mobiles and apple mobile and android mobiles and mac desktop and Linux desktop Please sir give me help for this case Thanks Rakesh Rajput

Author: David
Date: 18 Nov 2014 11:03
permalink

Johan, Well done on your work on getting JavaFX to mobile devices. I wish you the utmost success and request Oracle support you 100% in effort and finance with getting your solution polished and deployed TRANSPARENTLY on desktop and mobile app stores, and in pushing Google and Apple to assist. Letter to Oracle I emphasize TRANSPARENTLY for a reason, as this has always been an issue for Java. Sun invested millions in Swing and JavaFX development but fail at the most important hurdle - its delivery (WebStart). It's always frustrated me that after years of programming in Java, every time you want to run a commercial or demo of Swing or JavaFX using WebStart (even from a Oracle site), 85% of the time they never work because the browsers will not support it out of the box. Even after downloading the latest version of Java and restarting the browser the issue still exists. Lay people don't get this and just want things to work out of the box just like loading a HTML page or Flash. Therefore they see Java RAI as incomplete and why management refuse to consider RAI Java clients over HTML5. After 13 years of Java WebStart, the problem still exists and has never been addressed. This has always hindered Java from talking off on the desktop. Apologies for being blunt, but Oracle(Sun) need to take a feather from Apples hat and polish their delivery, otherwise all their and your hard work will be in a waste of time. Get this right Oracle. Success Johan David

Create comment