Wikibooks

J2ME Programming/The J2ME Platform

< J2ME Programming
(Redirected from Programming:J2ME:The J2ME Platform)
The latest reviewed version was checked on 11 February 2018. There is 1 pending change awaiting review.

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 communication 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, 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)

edit

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)

edit

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

edit

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

edit

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

edit

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

edit

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

JavaOS

edit

JavaOS ("JavaOS". JavaOS: A StandAlone Java Environment.) targets the underlying RealTimeOS (RTOS) structure of the OS that typically 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

edit

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

edit

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

edit

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:

  • Core Java classes
  • Java programming language features
  • Virtual Machine features

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

Connected Limited Device Configuration

edit

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:

  • "CLDC1.0". Connected Limited Device Configuration 1.0 JSR30. This Connected Limited Device Configuration 1.0 targets devices with 128k to 512k memory (256kROM/256RAM or less), limited power or battery operation, connectivity to some network at low speeds, and user interface.
  • "CLDC1.1". Connected Limited Device Configuration 1.1 JSR139. This Connected Limited Device Configuration 1.1 targets devices with 160K or more memory, processor speeds of 8-32MHZ, limited power or battery operation, and user interface. This configuration adds extends CLDC1.0 to included floating point math.

Connected Device Configuration

edit

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:

  • "Connected Device Configuration 1.0". Connected Device Configuration 1.0 JSR36. March 17. {{cite web}}: Check date values in: |date= and |year= / |date= mismatch (help) This Connected Device Configuration 1.0 targets devices with 512k minimum ROM/128k minimum RAM, connectivity to some network, supports a complete installation of a complete JVM, and more full featured user interfaces compared to CLDC.
  • "Connected Device Configuration 1.1". Connected Device Configuration 1.1 JSR218. March 17. {{cite web}}: Check date values in: |date= and |year= / |date= mismatch (help) This Connected Device Configuration 1.1 extends/updates the CDC1.0 to update J2SE APIs used in CDC1.0 to J2SE 1.4 APIs. Memory size was increased from 128k ROM to 256k ROM.

J2ME Profiles

edit

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

edit

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:

  • "MIDP1.0". Mobile Information Device Profile 1.0 JSR37. This Mobile Information Device Profile 1.0 extends the CLDC1.0 java environment in a vertical way to support MIDlet application development on devices targeted in the CLDC1.0 spec by providing a GUI toolkit, persistent data storage, messaging, networking components, and security. Although, attributes of JavaPhone and Java Telephony are mentioned in the spec; JavaPhone telephony attributes are not included as classes in MIDP1.0 but later on completed as a separate JSR and API package.
  • "MIDP2.0". Mobile Information Device Profile 2.0 JSR118. This Mobile Information Device Profile 2.0 extends MIDP1.0 to include https networking, the domain security model with digital certificates, formally includes OTA provisioning, push architecture of MIDlets responding to events, game functionality added to LCDUI, small xml parser, and a base sound API.
  • "MIDP3.0". Mobile Information Device Profile 3.0 JSR271. This Mobile Information Device Profie 3.0 extends MIDP2.0 to allow MIDlets to be auto-launched, run in background within the same VM, and enable inter-MIDlet communication. Extended functionality includes secure record stores/removable record stores, IPv6, multiple network interfaces per device, and additional MIDlet provisioning in addition to OTA.

Foundation Profile

edit

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:

  • "Foundation Profile 1.0". Foundation Profile 1.0 JSR46. This Foundation Profile 1.0 targets devices with 128k minimum ROM/512k minimum RAM, connectivity to some network, and no graphical user interface provided by this profile on top of the CDC1.0.
  • "Foundation Profile 1.1". Foundation Profile 1.1 JSR219. This Foundation Profile 1.1 is on top of the CDC1.1 which supports J2SE 1.4 APIs. Targeted devices memory is increased to 256k minimum ROM/512k minimum RAM. Some APIs included to specify functionality for IPv6, security, and more math support.

Personal Profile

edit

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 Profile 1.0". Personal Profile 1.0 JSR62. This Personal Profile 1.0 targets devices with 1.5Megs of minimum ROM/1Megs of minimum RAM, and a robust network connection is on top of the CDC1.0 and Foundation Profile1.0 and allows applications developed with pJava Emulation Environment Specification 1.1.x and 1.1.2 to run on devices targeted by this profile.
  • "Personal Profile 1.1". Personal Profile 1.1 JSR216. This Personal Profile 1.1 extends the Personal Profile 1.0 to update APIs to J2SE 1.4 and to make sure optional Graphics Packages derived from J2SE 1.4 APIs can be deployed on top of this profile. Devices targeted now are of minimum memory size of 3.5Megs ROM/3.5 RAM.

Personal Basis Profile

edit

This Personal Basis Profile provides a basic graphical user interface, i.e. 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:

  • "Personal Basis Profile 1.0". Personal Basis Profile 1.0 JSR129. This Personal Basis Profile 1.0 is deployed on top of the CDC1.0 and Foundation Profile 1.0 targeting devices with 2Megs minimum ROM/1Megs minimum RAM. the lightweight AWT apis are based on JDK1.1 not JDK1.3 APIs to meet the smaller foot print requirements.
  • "Personal Basis Profile 1.1". Personal Basis Profile 1.1 JSR217. This Personal Basis Profile 1.1 extends the Personal Basis Profile 1.0 by updating all APis to derived from J2SE 1.4 APIs to be compatible with optional graphics APIs such as AGUI.

Information Module Profile

edit

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:

  • "IMP". Information Module Profile JSR195. This Information Module Profile is a subset of MIDP1.0 missing the LCDUI classes.
  • "IMP-NG". Information Module Profile-Next Generation JSR228. This Information Module Profile-Next Generation si a subset of mIDP2.0 without the LCDUI classes.

Digital Set Top Box Profile

edit

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:

  • "Digital Set Top Box Profile". Digital Set Top Box Profile JSR242. This Digital Set Top Box Profile is a subset of Personal Java and JavaTV and is based on the current java classes in OCAP. Xlets developed with this Profile are upward compatible with the JavaTV (CDC, PP, and PBP) combination.

J2ME Optional Packages and APIs

edit

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:

  • "RMI". RMI Optional Package JSR66. The RMI Optional Package provides interoperable J2SE RMI support on top of the CDC and Foundation Profile.
  • "PDA". PDA Optional Package JSR75. The PDA Optional Package is on top of the CLDC and provides optional APIs common to PDAs and handsets. For example, the PIM functionality in JavaPhone makes its re-introduciton into J2ME Platform devices within this ooptional package. FileConnection API is added to allow GCF to access removable media storage.

J2ME Technology for the Wireless Industry

edit

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:

  • "Wireless Messaging API". Wireless Messaging API JSR120. The Wireless Messaging API provides classes to support messaging application development on the J2ME Platform.
  • "Mobile Media API". Mobile Media API JSR135. The Mobile Media API supports audio and multimedia on both the CLDC and CDC of the J2ME Platform.

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

edit

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 successful 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:

  • "Mobile Telephony API (MTA)". Mobile Telephony (MTA) JSR253. The Mobile Telephony API provides the classes to control the calls on both CLDC and CDC devices.

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

edit

Trademark Notices

edit

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

Retrieved from "https://en.wikibooks.org/w/index.php?title=J2ME_Programming/The_J2ME_Platform&oldid=4440677"