Comment: Oracle On The Road To “Write Once, Run Anywhere?”


Vice President of Development at Oracle, resurrected the old Java paradigm of “Write Once, Run Anywhere” during the Silicon Valley giant’s 27th January webcast, where Oracle unveiled their plans for Java ME and Java SE. Oracle proposed the unification of the SE and ME APIs, which would make it possible to write applications once, and then run them on a variety of devices – from mobile phones, to flat-screen TVs, to desktop computers.

A noble goal, to be sure – but is is feasible? In this article, Java ME expert Kay Glahn analyses Oracle’s plans regarding Java ME, SE and Java FX, and explains why he believes Oracle’s roadmap will have a positive impact, not only on the development community, but the entire industry………..

In his presentation, Thomas Kurian predicts the future of application development: as mobile devices become more powerful, the transition between desktop and mobile will blur. At the moment, it is challenging for the community to develop software for different devices, because of a high level of fragmentation between the different platforms and devices.

Oracle plans to solve these problems in a two-pronged attack. Firstly, by unifying the APIs of Java ME and Java SE, and secondly, by providing a consistent deployment platform for all different target devices. This is to ensure that applications can be written once and then run on different platforms.

As a developer, you won’t have to decide in advance whether you’re developing an app for the desktop or the mobile device. Oracle intends to make good on Java’s original promise of “Write Once, Run Anywhere” and create a uniform platform as it already exists on the server-side. According to Oracle, Java ME is available on around 2.6 billion mobile phones. It has huge potential. However, new devices and operating systems continue to fragment the programming model. At the same time, a convergence of device characteristics can be observed.

In my opinion, Oracle is on the right track. Fragmentation within the Java ME platform has been a huge problem for developers. Various initiatives such as MSA (Mobile Service Architecture) or JATAF (Java Application Terminal Alignment Framework) have already adopted this problem. However, there is still a fragmentation between Java ME and SE – although Java SE would be suitable for the current, more powerful mobile phones.

Then there is the Android Java platform, which has much more in common with Java SE than with Java ME. Until now, Sun has prevented the adoption of Java SE on a large scale within the mobile phone market with its Field of Use Restrictions in TCK-licenses. This has resulted in a proprietary Java environment based on Dalvik on Android devices. To get out of this dilemma, Oracle must find a way to make Java SE fit for mobile devices and unify it with Java ME. In an ideal world, this unification would include Android. But this is unlikely: Android already has an established market.

A good way to bring the latest Java SE on mobile devices, would be with the existing Sun Project Jigsaw. Jigsaw allows modularisation of Java SE and therefore could provide a stripped-down version for mobile devices, which would support current Java language features. In addition, there is already a convergence to the desktop-platform from the Java ME-side, with the introduction of the Java SE security model in MIDP 3 and MSA 2. This makes it easier to transfer mobile-specific APIs to Java SE. The Generic Connection Framework, which is often used by Java ME APIs, has been available for Java SE with JSR 197 for several years. Currently, it’s hardly ever implemented.

Oracle should also keep an eye on any future fragmentation of Java ME. A new approach in a re-vamped JCP could be helpful here. More transparency in the TCK tests and an open-source approach for TCKs would also be desirable.

In the webcast, Oracle also claimed they want to continuing investing in Java ME and improving the platform. They plan to improve the implementation, particularly in terms of performance and, amongst other things, accelerate the startup-time and runtime-speed. The power consumption during the execution will be reduced, which is particularly important for mobile phones, which have limited battery life. Oracle plans further improvements in the arena of new interaction paradigms, such as multi-touch. Currently, developers have  to find a way around different interaction paradigms – for example, devices with or without multi-touch support need different implementations. According to Oracle’s vision, in the future Java ME will allow developers to make only a single implementation for different input mechanisms.

I believe further optimisation of Java ME will be crucial to its future success. Java is often misinterpreted as a slow and sluggish platform. Offering optimised Java runtime environments for mobile devices with smooth UI interaction and a rich user experience – as we all know it from the iPhone – would be indispensable. It’s understandable that Oracle wants to support new interaction paradigms: if you look at the existing Java ME API, then you will notice that almost all of the ingredients for a competitive platform are  available – except a JSR for the support of Multi-touch interaction and similar mechanisms like gestures. Even MIDP 3 is omitted from this field. Urgent action is required.

Oracle wants to optimise Java through different runtime implementations, adapted to the respective  purpose of an application. On a server running in always-on mode, other conditions are relevant – whereas on a mobile device the virtual machine should be temporarily shut down wherever possible to conserve energy. However, the programming models should be unified as much as possible to allow portability across different environments and enable the widest coverage for the developer’s applications. An important piece in the Oracle strategy puzzle, is JavaFX, which will facilitate the portability to new platforms such  as IP TV, Blu-ray and future embedded devices. JavaFX is in a key position to provide a rich user experience on different devices. The Java ME implementations should be optimised accordingly for JavaFX. Oracle intends to continue delivering optimised binaries for network operators and device partners.

In my opinion, the lack of a really powerful user interface API is still the real weakness of Java ME. Even MIDP 3 is only a slightly revamped version of the outdated LCD UI. There are some proprietary alternatives, and Sun has also already launched its LWUIT UI project. However, none of these are standardised, and do not ship pre-installed on devices. A powerful and consistent UI is urgently needed. Java FX could be the solution here, but it is still open to debate whether an additional abstraction layer on top of Java is the way forward. So far, the acceptance of JavaFX in the industry and the developer community has been rather cautious. I believe JavaFX needs to prove whether it can prevail in the current market and whether it will be accepted as a standard UI for Java-based mobile devices.

It makes perfect sense to unify the programming models as much as possible, and provide a rich user experience across devices using JavaFX. But, in practice, it is often difficult to cover such wildly different devices as mobile phones and flat-screen TVs, with a single application. The hardware requirements such as display size and input methods are quite different. In practice, applications must differ significantly from one another if we are to deliver the optimal user experience for each device. It remains to be seen just how far JavaFX can establish itself as a universal Java UI abstraction layer.

The fact remains, that Oracle’s strategy for Java ME is certainly a positive sign for the developer community and the entire industry – both of which have, in recent years, invested considerable sums of money in the Java ME ecosystem. It is also encouraging that Oracle plans to continue investing in Java ME and in revitalising the Java developer community, and plans to further open-up the JCP (Java Community Process.)

Inline Feedbacks
View all comments