FeatureJAVA TECHNOLOGYToys or tools?FORTHEWIRELESS INDUSTRYby David Parsons, Ilan Kirsh,and Mark CranshawDavid Parsons is asenior lecturer ininformation <strong>sys</strong>tems atMassey University, Auckland,and a knowledge engineerfor S<strong>of</strong>tware EducationAssociates, Wellington.Until last year he wasthe director <strong>of</strong> emergingtechnologies at Valtech,London, and prior tothat, principal technologistat BEA Systems.d.p.parsons@massey.ac.nzThe Java Technology for the Wireless Industry specification(JTWI) encompasses a standard set <strong>of</strong> J2MEAPIs for mobile device development that is beingwidely adopted by mobile telephone service providers,making it an important platform for Java developers.Its core component, the Mobile Information DevicePr<strong>of</strong>ile (MIDP), provides a number <strong>of</strong> specialized librariesfor multimedia and games development; however,its underlying subset <strong>of</strong> general purpose Java classes isstrictly limited. In addition, support for persistence viathe Record Management System is relatively poor. Thisraises an important question: Is JTWI a realistic applicationdevelopment tool or is it only good for games andother s<strong>of</strong>tware trivia?In this article, we try to answer this question by exploringthe viability <strong>of</strong> MIDP as a tool for nontrivial applicationdevelopment. An enterprise application that includesmobile components might reasonably expect to devolvesome <strong>of</strong> its business processes and data management tomobile devices. Our chosen example, which <strong>con</strong>siders both<strong>of</strong> these aspects, is a proposed implementation <strong>of</strong> the JavaData Objects (JDO) specification. This includes a number <strong>of</strong>interesting features that highlight the <strong>con</strong>straints <strong>of</strong> workingwith J2ME APIs for limited devices. We describe the issuesaround the development <strong>of</strong> such an implementation andthe limitations that MIDP imposes, suggest some usefulworkarounds and architectural options, and finally drawsome <strong>con</strong>clusions about the usefulness <strong>of</strong> JTWI as a set <strong>of</strong>APIs for serious application development.IntroductionHandheld computers, such as the Pocket PC and the Palm,can support reasonably complete Java Application ProgrammingInterface (API) sets that can be used to develop seriousenterprise applications. However, smaller devices, such asmobile telephones, only support Java APIs that have beensignificantly reduced to work within the <strong>con</strong>fines <strong>of</strong> limitedhardware. There is no support for the types <strong>of</strong> persistencemechanisms that we have come to expect on larger Java platforms.The question we address in this article is whether themobile telephone is a viable platform yet for serious businessor scientific applications that need to store and process datalocally and that expect the services <strong>of</strong> a reasonably rich set <strong>of</strong>Java APIs.To date, we have seen <strong>con</strong>siderable development inareas such as mobile games development, but more seriousbusiness and scientific applications will need to be developedif JTWI is to be a useful component <strong>of</strong> enterprises<strong>of</strong>tware <strong>sys</strong>tems. Since such <strong>sys</strong>tems are likely to require<strong>con</strong>siderable support for persistence, we focus on the JDOspecification and examine some potential issues that arisewhen attempting to implement this specification usingMIDP. We extrapolate from this analysis to assess the generalusefulness <strong>of</strong> MIDP as a general purpose applicationprogramming platform. We also look at how MIDP devicesfit into larger distributed architectures that can mitigatethe limitations <strong>of</strong> mobile telephones as Java applicationplatforms.The Java 2 Micro Edition (J2ME)To cater to a wide range <strong>of</strong> small devices and applicationrequirements, the J2ME architecture (see Figure 1) providesmultiple <strong>con</strong>figuration and pr<strong>of</strong>ile layers that overlaythe specialized Java Virtual Machine (JVM) and operating<strong>sys</strong>tem. Configurations define the minimum set <strong>of</strong> availableJVM features and class libraries for a specific category<strong>of</strong> device and are hardware focused; pr<strong>of</strong>iles define the set<strong>of</strong> APIs available for a particular market category <strong>of</strong> devicesand are s<strong>of</strong>tware focused.J2ME <strong>con</strong>figurations specify the minimum requirementsfor memory, Java language features, JVM support, andruntime libraries. There are two standard J2ME <strong>con</strong>figurations:the Connected Device Configuration (CDC) and theConnected Limited Device Configuration (CLDC). For thesmallest portable devices, such as mobile telephones, thestandard <strong>con</strong>figuration is the CLDC. This <strong>con</strong>figurationrequires a very small virtual machine, such as Sun’s KVM(Kilobyte Virtual Machine) or CLDC HotSpot Implementation,with footprints <strong>of</strong> only about 50–80K. These virtualmachines don’t have to comply with the full JVM specification,nor do they have to support the complete Java languagespecification. API support is limited to a selection<strong>of</strong> classes from a few packages from the Java 2 StandardEdition (J2SE), plus the Generic Connection Framework(GCF), comprising a hierarchy <strong>of</strong> <strong>con</strong>nection interfaces(and the Connector factory class) that are intended toprovide a generic way <strong>of</strong> expressing operations on <strong>con</strong>nectionsregardless <strong>of</strong> the actual protocol.30 January 2005www.<strong>SYS</strong>-<strong>CON</strong>.com/<strong>JDJ</strong>
Java Technology for the Wireless IndustryThe key goal <strong>of</strong> the JTWI specification is “to minimize APIfragmentation in the mobile phone device market, and todeliver a predictable, clear specification for device manufacturers,operators, and application developers” (http://jcp.org/aboutJava/communityprocess/final/jsr185/index.html).Thus, we can reasonably expect the next generation <strong>of</strong>Java-enabled telephones to support these technologies. Thespecifications included within JTWI are:• Mandatory specifications:–Mobile Information Device Protocol (MIDP) 2.0–Wireless Messaging API (WMA) 1.1• Optional specification:–Mobile <strong>Media</strong> API (MMAPI) 1.1• Minimum <strong>con</strong>figuration on which JTWI is built:–Connected Limited Device Configuration (CLDC) 1.0From an application development perspective, the mostimportant API is MIDP (and by implication the CLDC uponwhich it builds), since these are the APIs that provide a subset<strong>of</strong> the standard Java packages found in the Java 2 StandardEdition, along with additional APIs specifically tailored formobile development. One important issue with JTWI is that itmandates only CLDC 1.0, not CLDC 1.1, which, as we will see,introduced some important new features.Mobile Telephone J2ME ApplicationCLDC (<strong>con</strong>figuration)J2ME Virtual MachineMIDP (pr<strong>of</strong>ile)Figure 1 The APIs for MIDP developmentAdditional Packages:• javax.microedtion.midlet• javax.microedition.lcdui• javax.microedition.lcdui.game• javax.microedition.media• javax.microedition.media.<strong>con</strong>trol• javax.microedition.rms• javax.microedition.pki+ additional classes from• javax.microedition.io+ the following classes:• java.util.Timer• java.util.TimerTask• java.lang.IllegalStateExceptionSubset <strong>of</strong> classes from p ackages:• java.lang• java.lang.ref• java.io• java.util+ additional package• javax.microedition.ioJava language syntax, but:• No finalization• Limited error and exception handling• Limits to threading• No user defined class loadersThe Mobile Information Device Pr<strong>of</strong>ileThe MIDP is one <strong>of</strong> two pr<strong>of</strong>iles (the other being the InformationModule Pr<strong>of</strong>ile) that works on top <strong>of</strong> the CLDC. Itprovides graphical interfaces for interactive applications andis the standard Java pr<strong>of</strong>ile for mobile telephone developmentunder the JTWI specification.There are seven packages <strong>con</strong>taining the additional classesand interfaces <strong>of</strong> the MIDP, providing user interface featuresat two levels <strong>of</strong> portability, sound support, certificate-basedauthentication, persistence, and the MIDlet framework for deployingclasses into a MIDP environment. There are also extraclasses in the javax.microedition.io and java.util packages.The sum <strong>of</strong> APIs available to a MIDP developer will be thecombined set <strong>of</strong> classes in the CLDC and MIDP. Figure 1 summarizesthe relationships between the relevant <strong>con</strong>figurationand pr<strong>of</strong>ile APIs and the underlying J2ME JVM.What Is Missing from MIDP?To <strong>con</strong>sider how viable MIDP is as a general-purpose programmingframework, it’s useful to explore which packagesand classes are excluded from it when compared with thestandard edition. Of course, MIDP provides its own classes forgraphics and sound, so there are no AWT, Swing, or sound-relatedpackages from the standard edition. Similarly, MIDP hasits own (limited) security classes, so there are no javax.securitypackages either. Since the Generic Connection Frameworkcovers <strong>con</strong>nectivity, packages relating to CORBA and network<strong>con</strong>nections are also excluded. RMI likewise is not part <strong>of</strong>MIDP; although there is a separate J2ME RMI pr<strong>of</strong>ile, it canonly be used with the CDC <strong>con</strong>figuration, not with CLDC.Other missing packages are those that relate to JavaBeans,reflection, XML, printing, and JNDI.Although MIDP excludes many packages that are presentin the standard edition, many <strong>of</strong> these have equivalents in theMIDP packages or, like printing, are not particularly importantfor mobile devices. However, it is in those packages that areincluded in MIDP that we find the most <strong>con</strong>straining factors,since these packages have far fewer classes in MIDP than in thestandard edition. For example, MIDP includes only one interfaceand nine classes from java.util, as opposed to 14 interfacesand 41 classes in the standard edition (version 1.4), principallydue to the absence <strong>of</strong> the Java 2 Collections Framework.MIDP Persistence with RMSIn the <strong>con</strong>text <strong>of</strong> enterprise Java development, there are anumber <strong>of</strong> standard APIs that can be used to support data and/or object persistence: serialization, JDBC, Java Data Objects,and entity Enterprise JavaBeans (Enterprise Edition only). In<strong>con</strong>trast, MIDP does not automatically support any <strong>of</strong> thesepersistence mechanisms. The CLDC java.io package <strong>con</strong>tainsonly the lower-level streams, readers, and writers, and doesn’t<strong>con</strong>tain any file or object streams, or, indeed, the Serializableinterface.This means that persistence-related code in MIDP differs<strong>con</strong>siderably from other Java programming <strong>con</strong>texts and usesthe Record Management System (RMS). The RMS comprisesvariable length record stores, each <strong>of</strong> which is a collection<strong>of</strong> variable size binary data records. Each record store hasa unique name, and each record within a store has a nonreusableinteger index that acts as a primary key. Althoughindividual operations on a record store are atomic, there is notransactional support, apart from a version number, that canbe used to support manually implemented locking strategies.The Java Data Objects SpecificationThe Java Data Objects specification is an output <strong>of</strong> the JavaCommunity Process (JSR 12), which had its first final releasein April 2003. JDO defines an interface-based standard for thepersistence <strong>of</strong> domain objects. There are currently around 20vendors <strong>of</strong>fering JDO implementations with varying levels <strong>of</strong>specification compliance. JDO implementations can be usedwith a range <strong>of</strong> data stores and across all three editions <strong>of</strong> theJava 2 platform and is a recommended persistence mechanismfor data-centric applications on mobile devices.JDO can be used in the <strong>con</strong>text <strong>of</strong> a nonmanaged or a managedscenario. The former case refers to a typical two-tier orembedded application, the latter to a server-based architectureIlan Kirsh is a lecturer inComputer Science at theAcademic College <strong>of</strong>Tel-Aviv-Yaffo, and the author<strong>of</strong> ObjectDB (www.objectdb.com), a pure JDO objectdatabase for J2EE, J2SEand J2ME.kirsh@objectdb.comMark Cranshaw is a seniorlecturer in the Faculty <strong>of</strong>Technology at SouthamptonInstitute. He has extensiveexperience <strong>of</strong> deliveringeducation using Javatechnologies, including JDOtools. His current researchinterests include mobileJava and HCI.mark.cranshaw@solent.ac.ukwww.<strong>SYS</strong>-<strong>CON</strong>.com/<strong>JDJ</strong>January 200531