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

jt
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.)

Author
Comments
comments powered by Disqus