J2ME Programming/The J2ME Platform

< J2ME Programming

Java 2 Platform, Micro Edition, or J2ME, is a collection of Java APIs targeting embedded consumer products such as PDAs, cell phones and other consumer appliances.

J2ME has become a popular option for creating games for cell phones, as they can be emulated on a PC during the development stage and easily uploaded to the phone. This contrasts with the difficulty of developing, testing, and loading games for other special gaming platforms such as those made by Nintendo, Sony, and others, as expensive system-specific hardware and kits are required.

Often, introductions of J2ME gloss over areas that the beginning J2ME developer might improve their learning process and hopefully this set of articles will remove that obstacle. What we will cover is the history leading up to J2ME's birth and beyond. We will also cover the complexity of the whole J2ME API ecological system and hopefully this will help you in your J2ME development projects and applications.

Overall, the change from analogue to digital in both devices and infrastructure serving those devices has been the third unseen character in this J2ME evolution. Changes from analogue methods of cellular communciation to such standards as CDMA, TDMA,and WCDMA. Also, drastic changes in the vehicle computing and digital tv realm involving new standards such as DVB, MHP, HAVi, MPEG4, OSGi, and etc have changed how computer languages such as Java and the J2ME platform interact with this new area.

A brief history of Java on Mobile Devices (pre-platform and pre-jcp)

This history is called pre-platform and occurs before the 1999 Sun event of renaming java portions as platform editions. In the 1992 time span Sun Microsystems Engineers and Venture Capital funded Startups contributed to a project called Green ("Green". The Brief History of the Green Project. ) to bring new Virtual Machine execution framework to embedded devices. The device was called Star7 and was powered by a SPARC CPU.

The language which was called OAK at the time and its features were the result of the merge of FirstPerson, ON, and Sun Microsystems. Although, not mentioned in this brief history ("Java 5th Birthday". JAVA TECHNOLOGY: THE EARLY YEARS. ). The first JVM was in fact completed by ON and based on Smalltalk according to The official Wiki version of history of Java Language ("Java History". The official Wiki version of history of Java Language. ). Thus, the having the small foot print of a Virtual Machine not only benefited the birth of Java but its steady climb during this period into browsers and the start of its rebirth into mobile devices.

Although Sun Microsystems concluded that some of its role during this period was to drive the Consumer Device market away from WINTEL to SPARC processors it was the application killer app side that survived this risky startup time period.

PersonalJava (pJava)

Sun's second exploration of java on mobile devices was centered around the idea of deploying a subset of JDK1.1.8 ("JDK1.1.8". Java Development Kit 1.1.8_10. ) on mobile devices that have a more in depth display as opposed to just a character display. At this time, around 1998, one of the target devices for PersonalJava was set boxes as evidence by press such as McNealy touts Java on set boxes ("McNealy". McNealy touts Java Everywhere, TCI deal. ).

As the PersonalJava spec ("PersonalJava spec". PersonalJava API Specification. ) was introduced in 1998 it was nicknamed pJava by Sun Microsystems. Because pJava uses a subset of JDK1.1.8, SUN Microsystems released a pJava Emulation Environment ("pJava Emulation Environment". PersonalJava Emulation Environment. ) to assist developers in testing their applets and applications for pJava Compliance.

EmbeddedJava

EmbeddedJava ("EmbeddedJava". EmbeddedJava Application Environment. ) was based on JDK1.1.6 ("JDK1.1.6". JDK1.1.6 Download. ) and was targeted for those mobile devices that only had a character display.

JavaPhone

The Mobile device OEMs found that the PersonalJava and EmbeddedJava solutions lacked those APIs that would allow access to pure telephony functionality on Mobile Devices. Thus JavaPhone API ("JavaPhone". JavaPhone API. ) was designed by Sun Microsystems to be vertical expansion of PersonalJava to add telephony functionality to deployed java solutions on Mobile devices.

JavaTV

JavaTV ("JavaTV". Java TV API. ) is designed to provide java apis for the set box and headless network terminals beyond what PersonalJava provides that are specific to the iTV/DTV platform such as HAVi, DVB-MHP, and etc.

AutoJava

AutoJava was also a 1998 Sun Microsystems push into telematics (Auto) and did not get enough traction to survive as a separate api.

JavaOS

JavaOS ("JavaOS". JavaOS: A StandAlone Java Environment. ) targets the underlying RealTimeOS (RTOS) structure of the OS that typcially is deployed on Mobile Devices or Embedded Devices. JavaOS was launched by SUN Microsystems in the fall of 1996 and was based on the JDK1.0. ChorusOS which was bought during JavaOS development by SUN Microsystems was later spun off as ChorusOS ("ChorusOS OpenSource". ChorusOS Open Source. ).

Birth of J2ME

As you can see by this NewsFlash ("SUN NewsFlash". SUN ANNOUNCES KEY CONSUMER TECHNOLOGY TO BRING THE POWER OF THE JAVA PLATFORM TO AUTO, TV AND PHONE MARKETS. ) in the spring of 1998 the Mobile Device market was being stormed by java but not in a very structured fashion. As you can see from an Interview of the Father of KVM ("Interview of the Father of the KVM". J2ME Luminary Antero Taivalsaari. ) Sun was behind the scenes responding to this fragmentation in the Mobile Device space by innovating a new JVM for Mobile Devices and the first set of J2ME platform specs and as a project was nicknamed Spotless.

J2ME is Alive

In the time period of 1998-1999 SUN Microsystems reveals its behind the scenes work in defeating fragmentation in the Mobile Device space by announcing the formation of the Java Community Process and reorganizing these fragments of java apis for mobile devices into the J2ME, Microediton Platform. Let us now go over how J2ME is organized against API fragmentation in the Mobile Device space.

J2ME Configurations

Sun Microsystems came up with the idea that a configuration API would cover the runtime aspects of J2ME deployed on a device. The smallest J2ME configurations are actually subsets of the largest J2ME configuration. The runtime aspects are covered by having these specific classes in the configuration api:

Currently, there are the configurations of CLDC (Connected Limited Device Configuration) and CDC (Connected Device Configuration).

Connected Limited Device Configuration

The CLDC covers devices below 512k size of memory for the JVM environment and removes JNI, user defined class loaders, some class verification items of the class verification process (the reason why we MIDlet Preverify MIDlets compiled to be deployed on CLDC devices) and reflection to fit into this small footprint. The JVM on CLDC devices is called KVM (K-VirtualMachine), nicknamed K-VirtualMachine for kilobyte. The application lifecycle concepts from javaTV and the installation concepts of javaPhone found their way into this Connected Limited Device Configuration. The JSRs for CLDC are:

very good

Connected Device Configuration

The CDC covers devices above the 512k size of memory for the JVM environment. The garbage collector is a separate pluggable item into the CVM deployed on CDC devices. The threads are implemented not as OS specific but as fully implemented threads within the CVM and are known as Green Threads. Threads can also be implemented as OS native threads. Class file verification takes place in the CVM on the device just as in J2SE java platform on desktop systems. The JVM on CDC devices is known as a CVM or the C-VirtualMachine. The JSRs for CDC are:

J2ME Profiles

Profiles provide APIs that focus on a specific group of devices. These devices typically have the same or similar user interfaces (screen and inputs), how the device connects to the network, how the device stores data, and etc. Currently, the Profile Name indicates the Family name of this group of devices or a common functionality with this group of devcies. For example, the MIDP (MID Profile) is for the group of Mobile Information Devices. J2ME Profiles are:

Mobile Information Device Profile

The Mobile Information Device Profile extends and enhances the CLDC to provide a Java environment to develop applications on Mobile information appliances and voice communication devices. The JSRs for this profile are:

Foundation Profile

The Foundation Profile is what can be called a vertical specification profile. A vertical specification profile specifies the targeted family of devices by memory size and the optional profiles that may plugin more functionality in addition to this profile. The GUI APIs are often Profiles plugged in on top of this Profile. Typical rich network devices include set top boxes (iTV), auto-computing (telematics), and etc. The JSRs for this profile are:

hi am the one who wrote it.

Personal Profile

This Personal Profile provides high web fidelity to device with a rich network connection and can use the heavy weight applet classes that were part of the PersonalJava spec. While Personal Profile, JSR62, supports PersonalJava1.1.x and PersonalJava1.2.x of the PersonalJava Application Environment; Personal Profile 1.1 supports the adoption of the subset of J2SE1.4 APIs as Personal Profile 1.0 was based on the subset of J2SE1.3 APIs. The JSRs for this profile are:

Personal Basis Profile

This Personal Basis Profile provides a basic graphical user interface, ie the AWT lighweight APIs, on top of the CDC and Foundation Profile and is considered as a subset to the Personal Profiles. This profile also provides the xlet classes required for JavaTV. The JSRs for this profile are:

Information Module Profile

This Information Module Profile supports embedded network connected devices without a graphical user interface. This profile is a subset of the MIDP1.0 profile without the LCDUI classes of MIDP1.0. The typical devices target are modems, household devices, and industrial metering devices. While IMP is a subset of MIDP1.0, IMP-NG is a subset of MIDP2.0. The JSRs for this profile are:

Digital Set Top Box Profile

This Digital Set Top Box Profile is a subset of JavaTV and is targeted for the smaller set top boxes that deploy OCAP. Thus, this profile differs from the javaTV (CDC, PP PBP) setup in that its on top of CLDC not CDC to support a smaller device memory foot print. However, several concepts are borrowed from the JavaTV items in Personal Basis Profile such as the xlet lifecycle. The JSR for this profile is:

J2ME Optional Packages and APIs

During 1999 to 2001 the concept of J2ME Optional Packages and APIs was introduced to provide additional packages and APIs on top of J2ME Profiles to add specific functionality to certain classes of devcies. Some profile JSRs were changed to this new Optional Package concept:

J2ME Technology for the Wireless Industry

Due to the increasing complexity of J2ME, JTWI was proposed in 2002. The J2ME Technology for the Wireless Industry, also known as "JTWI1.0". JSR185. , sets a clear architecture concept of what optional packages and APIs match up with which Profiles. This concept covers CLDC1.0, CLDC1.1, CDC1.0, and MIDP2.0 family of devices. The optional packages and APIs are:

The 2nd version of the JTWI2.0 was split along CLDC and CDC configuration lines into is "JSR248". JTWI2.0 Mobile Service Architecture for CLDC.  and "JSR249". JTWI2.0 Mobile Service Architecture for CDC. 

Conclusion

Although, other OS specific solutions such as extending C/C++ to the mobile platform has gotten its first burst of adoption; preliminary work in the forms of javaPhone, javaTV, embeddedJava, PersonalJava, and establishment of the J2ME Platform provided the basis for the successfull push of J2ME and its steady climb to become the market leader on mobile devices. While, not all of JavaPhone functionality is in full MIDP devices as of yet; this other API brings rest of the JavaPhone to the J2ME Platform:

As we head into the future of Mobile Devices, the Java Community Process Contributors to the J2ME Platform have been busy creating new JSRs to cover new advances Mobile Technology. For example:

References

Trademark Notices

J2ME, Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

This article is issued from Wikibooks. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.