"Java everywhere" is for world domination

Why the latest wireless buzz matters to all developers

Before the Java language was known as Java, it was called Oak—a language for building embedded applications on smart consumer electronics. However, the idea of networked smart devices everywhere was beyond its time in the 1990s. Instead, Java took off as an Internet language to enhance thin client browsers (applets) and went on to become hugely successful as a server-side platform (servlets and Java 2 Platform, Enterprise Edition (J2EE)). However, the vast and profitable client software sector remains elusive to Java developers. Microsoft's Windows monopoly remains unchallenged despite the availability of cross-platform Java GUI (graphical user interface) toolkits. As the application server market is growing increasingly saturated and the J2EE servers are becoming low-margin commodities, the growth of Java is at a critical conjunction.

Fortunately, the winds for Java on the client side have recently changed. As smart wireless device shipment far exceeds PC shipment this year, the Windows PC is no longer the de facto client platform. In a keynote speech delivered to Microsoft developers in March 2003, Bill Gates likened today's wireless market to the "early days of Windows," where there are huge opportunities for profits and new jobs, and no dominant player. The opportunity for Java to become a truly ubiquitous end-to-end platform has finally come.

The "Java everywhere" vision initiated by Sun Microsystems during the 2003 JavaOne conference aims to promote Java in the huge emerging market of end-to-end solutions. In this article, I discuss "Java everywhere," what kind of applications it supports, and what it means to developers.

What is "Java everywhere"?

In technical terms, "Java everywhere" is a single-architecture, end-to-end solution. The Java platforms on the server side (Java 2 Platform, Enterprise Edition, or J2EE), client side (Java 2 Platform, Standard Edition and Micro Edition, or J2SE and J2ME), and inside embedded devices (J2ME and JavaCard) share the same basic language features, API designs, libraries, and even development tools. The value proposition of "Java everywhere" for developers is to maximize productivity and allow existing developers to enter emerging markets without extensive retraining.

The J2SE and J2EE architectures are relatively stable after years of development and the maturity of the PC platform. But on the mobile client end, the platform is still evolving quickly. The need to work with many device manufacturers and network operators has made the exact J2ME specification a moving target.

However, getting J2ME right proves crucial to the financial success of "Java everywhere." The projected device market is not only much larger, but also much more profitable than the PC market since mobile customers are more likely to pay for their services. "Java everywhere" envisions Java runtimes in every smart device manufactured. It is an ambitious goal. But if successful, "Java everywhere" not only creates new opportunities, but also helps to revive the other Java-related IT sectors. To get Java working properly on all devices, we must compromise one of Java's most recognized principles: Write Once, Run Anywhere (WORA).

Bigger than WORA

Focused on architectural consistence and skill transfer, "Java everywhere" is bigger than the traditional WORA principle. Due to resource constraints on small devices, we cannot run J2SE applications directly on smart devices. The architecture of the J2ME platform itself consists of configurations and profiles, each supporting a different subset of J2SE core language libraries. The universal WORA principle is compromised because we can no longer expect a Java application to run on all J2SE and J2ME devices. WORA only applies to devices within the same J2ME profile.

Even for similar devices, such as smart phones, the standard J2ME profile (e.g., the Mobile Information Device Profile, MIDP) only specifies a set of lowest-common-denominator APIs and features every device must support. However, the device market is known for fast-paced innovation. Manufacturers differentiate their devices by offering new features and new capabilities (e.g., from PDA phone to camera phone, to video phone). It is crucial for Java developers to use those new features to develop compelling applications.

In the current J2ME architecture, support for those advanced device features is available through optional packages. Optional-package APIs are developed and standardized in the JCP (Java Community Process). They let developers write portable applications for similar devices. Today, MIDP optional packages support most modern smart phone features: from SMS (Short Message Service), multimedia content, Bluetooth connectivity, and GPS (global positioning system) to SOAP (Simple Object Access Protocol) Web services. The optional-package approach has even ported back to the J2SE space. For example, JSR (Java Specification Request) 197 ports the J2ME Generic Connection Framework (GCF) to J2SE. It allows J2ME network applications to run on J2SE PCs.

Of course, many optional packages can be sometimes confusing. Consolidation efforts are underway. One of the most important efforts is JSR 185, Java Technology for the Wireless Industry. The JSR 185 expert group consists of big device manufacturers and wireless carriers. The JSR defines the relationships and interactions among different components in the J2ME architecture. JSR 185 provides documentation, TCK (Technology Compatibility Kit) suites, and guides for both users and manufacturers.

Device vendors can also help developers by categorizing devices according to the features and the APIs they support. A good example is Nokia's Series 30, 40, and 60 developer platforms.

Developer tools are the key

For the "Java everywhere" vision to succeed, developers must adopt Java to solve real-world end-to-end mobility problems. Now let's look at what developers the vision might attract:

  • There are 3 million Java developers today. Many will enter the smart device sector in the future because that is where the money and jobs are.
  • Most current device developers use C/C++. As the Java runtime performance drastically improves, many of these developers are looking into Java as a more secure and productive choice.
  • Low-end corporate developers with Visual Basic (VB) skills and client-side development experience are looking for migration choices. They could migrate either to the Microsoft .Net platform or the Java platform.

To attract those developers to the Java camp, powerful and familiar development tools are key. The new language features in the upcoming J2SE 1.5 largely aim at reducing Java's complexity. Innovations such as a Java metadata facility (JSR 175) and a Java IDE extension API (JSR 198) make it easier to develop first-class Java development tools.

During the 2003 JavaOne conference, Sun revealed the Project Rave prototype IDE for enterprise Java developers. In many ways, Project Rave resembles Microsoft Visual Studio .Net. It is designed to attract migrating VB developers to the Java camp. During the conference, Sun also demonstrated Project Relator, a tool that targets enterprise mobility developers for seamless integration between J2ME clients and J2EE backend servers.

In the J2ME space, developer tools are thriving. All major Java IDEs now support J2ME development. The challenge now is to make them support more device-specific libraries and emulators. During JavaOne, Borland and IBM announced that JBuilder and WebSphere Studio Device Developer (an Eclipse-based IDE tool) would feature support for Nokia devices.

In the following section, we look at J2ME in more detail.

"Java everywhere" and J2ME

As announced at JavaOne, Java runtimes are built into more than 150 devices from more than 20 manufactures. All five major cell phone manufactures have committed to the Java platform. In addition to manufacturer support, Java has also gained widespread support from the wireless carrier community. Wireless carriers are conservative and wary of any security risks imposed by new technologies. As part of the J2ME specification process, carriers can influence the platform with their requirements. As a result, all major wireless carriers around the world have announced support for J2ME handsets and applications. For developers, J2ME applications can take advantage of not only ubiquitous device support, but also ubiquitous network support.

A major effort has been made to support games on J2ME handsets. Mobile entertainment has proven to be an extremely profitable sector. In Europe, simple ring-tone download has generated .4 billon in revenue last year. In comparison, the entire global J2EE server market is .25 billion. J2ME games are content rich, over-the-air downloadable, and micro-payment-enabled. The J2ME gaming sector is projected to grow explosively and create many new Java jobs in the next couple of years. In fact, J2ME games are already the second largest revenue source for Vodafone's content service.

Notable recent advances in the J2ME space are listed below:

  • The Mobile 3D Graphics API for J2ME (JSR 184) promises to bring 3D action games to Java-enabled handsets. Nokia presented an impressive demonstration at JavaOne.
  • The Advanced Graphics and User Interface Optional Package (JSR 209) will provide Swing and Java 2D support on PDA-type devices. At JavaOne, SavaJe Technologies, a smaller vendor, demonstrated a prototype smart phone device running Java Swing.
  • IBM has already ported its SWT (Standard Widget Toolkit) UI framework to Pocket PC devices as part of its Personal Profile runtime offering.
  • The Location API for J2ME (JSR 179) enables novel applications not possible in the desktop world. The API can determine a user's location either from a built-in GPS device or from a phone operator's triangular location signals in compliance with the enhanced 911 government requirements.
  • The completion of the SIP (Session Initiation Protocol) API for J2ME (JSR 180) enables the development of instant messaging applications on mobile devices. That will finally facilitate convergence between the popular desktop IM applications and wireless SMS messaging systems.
  • The Security and Trust Services API for J2ME (JSR 177) allows J2ME phones to access the device's embedded security element (e.g., the SIM (Subscriber Identity Module) card for GSM (Global System for Mobile Communications) phones). JSR 177 enables support for more powerful and flexible security solutions for financial and other mobile commerce applications.
  • The J2ME Web Services Specification (JSR 172) supports Web services clients on mobile devices.

The push for "Java everywhere" has proven fruitful for the development of the J2ME specifications.

"Java everywhere" for enterprise developers

Since "Java everywhere" seems so focused on the mobile client, many enterprise Java developers have the perception that it has nothing to do with them. After all, not everyone wants to start a new career to develop games. However, "Java everywhere" is more than relevant for enterprise developers since enterprise applications must be designed to work with their clients. In fact, many recent J2EE innovations ease life for J2EE developers who want to support mobile clients.

In this section, I discuss enterprise mobility, existing tools, and challenges.

Enterprise mobility

If the consumer mobility market is about toys to kill time, the enterprise mobility market is about tools to save time. As companies invest to improve productivity in sales forces, field agents, supply chain management, and on the factory floor, adding mobility to existing enterprise IT infrastructure is a top priority. For developers, mobile enterprise applications are often more profitable than consumer applications since the developer, not the wireless carrier, owns the customer.

Existing tools in J2EE

Several emerging J2EE specifications and products allow us to extend our HTML browser-based Internet applications to WAP/WML-based (Wireless Application Protocol/Wireless Markup Language) phone devices:

  • The JavaServer Faces specification clearly separates J2EE applications into layers according to the MVC (Model-View-Controller) pattern and supports rich server-side controls. It is easy to plug in a WML UI to any JavaServer Faces application.
  • The J2EE Portlet Specification (JSR 168) allows us to build portals with both HTML and WML interfaces.

The thin client is not the answer

Currently, most existing J2EE tools focus on WAP/WML thin clients, but not J2ME clients. This major issue must be addressed before "Java everywhere" becomes a reality because thin client mobile solutions proved unsuccessful during the last mobile commerce hype in the late 1990s. Thin clients' requirements for a fast, reliable wireless network are simply not realistic. J2ME-based smart clients provide the much needed enterprise features on the device. These features include:

  • Superior security
  • Rich user interactions
  • Transactions
  • High performance by eliminating round trips
  • Quality of service over messaging
  • Support for offline mode and multitasking
  • Synchronization support

This list continues. For a detailed discussion of WAP versus J2ME, please refer to the upcoming book Enterprise J2ME.

Several projects have already started to help integration between the J2EE back end and J2ME front end. They include the previously mentioned Project Relator from Sun, the J2ME Web Services API, and IBM's WebSphere Studio Device Developer IDE.

Now let's look at exactly where J2EE developers fit in building smart client-based enterprise solutions.

Skill transfer

In a smart client solution, the client-side developer takes the driver's seat. The smart client controls the application's complete flow and data logic. The back end is just an RPC (remote procedure call) end-point, a remote peer, or a message recipient buried in the application to delegate some heavy tasks from the mobile device.

Designing and implementing such sophisticated applications requires considerable skills. Enterprise Java developers are trained for complex design patterns and coding best practices. Transferring their skills to a new arena is easy. Here are just some examples on how you can apply your J2EE skills in a mobile application:

  • The Sun wireless blueprint application, Java Smart Ticket, is a good example for end-to-end MVC designs. The entire J2EE back end is behind a façade inside the model layer.
  • The IBM Service Management Framework is an implementation of OSGi (Open Services Gateway Initiative) containers. It allows us to run Java servlets right on a PDA device. The PDA's native HTML browser accesses the servlet on a local host. The servlet can then retrieve data from backend services. It acts as a smart client from the backend point of view. The OSGi framework handles application provisioning, life cycle management, and common application services (e.g., logging). Developers can apply familiar J2EE design patterns and best practices to the J2ME application.
  • Several relational database engines are already available on J2ME devices including the smallest MIDP phones. Those mobile databases synchronize with backend enterprise databases to support low bandwidth or occasionally connected mobile applications. Common JDBC (Java Database Connectivity) and data persistence best practices are directly applicable here. For more information on J2ME mobile databases, please refer to one of my previous Wireless Java columns, "High-Availability Mobile Applications" (June 2003).

More discussions on mobile application design patterns and best practices can be found in my upcoming book Enterprise J2ME.

Client-side Java revolution begins

The central message from this year's JavaOne is that the long overdue Java client-side revolution has finally arrived in the form of "Java everywhere." To paraphrase JavaOne keynote speaker Guy Laurence from Vodafone: the Java mobility train has already left the station, you are either on board or not. Every time you pick up your Java-enabled cell phone, think about the opportunities you might have missed.

Michael Yuan is a PhD candidate at the University of Texas, where he is a research associate at the Center for Research in Electronic Commerce and an open source Java developer.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies