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.

Mobile JavaFX Enterprise at JavaOne

I am glad the two session proposals I submitted for JavaOne are both accepted. I will be talking about DataFX and about JavaFX on Android. In this blog post, I try to explain why I focus on exactly these two topics.

There are a number of tendencies in the IT industry that we can’t ignore.  

Mobile is overtaking the desktop

As shown in the article at http://money.cnn.com/2014/02/28/technology/mobile/mobile-apps-internet, people today spend more time using devices than using a desktop. Desktops and laptops still hold a strong part of the market, but the mobile devices (mainly smartphones and laptops) are simply more relevant today.

Apps haven overtaken browsers

The same article shows that in the case of mobile, the use of applications outnumbers the use of web browsers.

If we combine both trends, we can conclude that the market of mobile applications is a very interesting one. That doesn’t mean web browsers and traditional web sites are vanishing very soon, but it clearly shows the hot spot is shifting from web pages to mobile applications.

The two major platforms for mobile devices, Apple’s iOS and Google’s Android, dwarf the other platforms. While you can write applications using Objective C for iOS, or the Android SDK for Android devices, I believe there are a number of advantages in writing your application in Java, using JavaFX as the User Interface platform.

• cost efficiency: there is no reusability of code between an Objective C application and an Android application. Using Java and JavaFX, developers can leverage the “write once, run anywhere” paradigm of Java.
• portable to the desktop: the success of appstores for mobile devices is starting to influence the desktop. We see a growing number of application stores for desktop operating systems. The same JavaFX application that is being used on a mobile device can also be used on desktop devices. The use of CSS or separate skin classes can lead to a combination of same codebase yet platform-familiar look and feel.
• JavaFX is simply a great interactive user interface platform. I like the Android services (and they are very interoperable with JavaFX, so they can be used in a JavaFX application), but for UI development, JavaFX is the clear winner for me.

In Session CON1804, Running JavaFX Applications on Android, we will discuss the current state of JavaFX on Android, provide an overview, show how to create a JavaFX Android application, and talk about future plans.

 

Another trend is the growing interest in (REST-based) “microservices” at the back-end. This is important for client applications as well. A typical business application makes a number of requests to a back-end, and expects responses as well. Mobile devices are getting more and more powerful, but still they cannot be compared with servers, clusters of servers, or a cloud environment. Many of the techniques used in server-side software simply won’t work on (mobile) devices. It is extremely important, though, that client applications can easily interact with back-end applications. This is where the DataFX framework helps. The JavaFX Platform provides a great client platform, with a strong focus on the user interface and interactions. DataFX extends the JavaFX Platform by providing components that can be used to communicate with back-end systems, and by providing a simple API that allows developers to define the flow between different parts and views of the application. We will discuss DataFX in Session CON 3640, DataFX: From External Data to a UI Flow and Back .

I preferred to focus on 2 presentations in a single area, but that does not mean I have no interest in other areas. I am still watching the evolutions for Java EE 8 from as close as I can, since I realize this is a very important piece of the whole end-to-end puzzle. Looking at the presentations in the Java server-side track, I’m convinced this is going the right way.

I hope to see many developers at JavaOne. Those are interesting times, let’s make the difference.