When the Java 2 Platform, Micro Edition (J2ME) was first introduced, only one configuration, the Connected Limited Device Configuration (CLDC), and one profile, the Mobile Information Device Profile (MIDP) had been defined as formal specifications through the Java Community Process (JCP). Today, there are nearly forty J2ME-related specifications at various stages in the JCP, and many of these specifications define optional packages instead of configurations or profiles. This article explores what optional packages are and how they're used. We also look at a few of the optional packages defined by the JCP.
Initially, the J2ME platform consisted only of configurations and profiles.
A configuration defines the minimum Java runtime environment for a family of devices: the combination of a Java virtual machine (either the standard J2SE virtual machine or a much more limited version called the CLDC VM) and a core set of application programming interfaces (APIs). At this writing there are two configurations in J2ME, and no plans to add others. The first, the CLDC, is for very constrained devices. The second, the Connected Device Configuration (CDC), is a superset of the CLDC that more closely resembles a standard J2SE runtime environment.
A profile is a set of APIs added to a configuration to support specific uses of a device. Profiles define complete, and usually self-contained, application environments. Profiles often, but not always, define user interface and persistence APIs; the MIDP fits this pattern. Profiles may be supersets or subsets of other profiles; the Personal Basis Profile is a subset of the Personal Profile and a superset of the Foundation Profile.
The initial flurry of J2ME specification activity centered on the development of new profiles. As the platform evolved, however, it became obvious that developers needed a third category of J2ME component, the optional package. It was also clear that the overall architecture of the J2ME platform needed more precise definition. A Java Specification Request (JSR) formally defining the platform was created. The J2ME Platform Specification (also known by its specification number, JSR 68), defines J2ME configurations, profiles, and optional packages in terms of lower-level elements. JSR 68 is currently in the community review phase of the JCP. (For more information on JSR 68, see the specification on the JCP web site.)
JSR 68 is primarily of interest to the expert groups defining other J2ME specifications, not the average developer. One of its goals is to prevent the creation of similar but incompatible APIs. The reuse of existing APIs, whether those APIs are defined by J2ME, J2SE, or J2EE, is strongly encouraged whenever possible. Reuse prevents unnecessary fragmentation of the Java platform as a whole and promotes code portability across its three editions.
An optional package is also a set of APIs, but unlike a profile, it does not define a complete application environment. An optional package is always used in conjunction with a configuration or a profile. It extends the runtime environment to support device capabilities that are not universal enough to be defined as part of a profile or that need to be shared by different profiles.
Consider the Wireless Messaging API (WMA), a set of classes for sending and receiving Short Message Service (SMS) messages. Because the WMA is an optional package, it can be included on any J2ME device with SMS capabilities, not just MIDP-enabled cellphones. If WMA were part of a specific profile, such as MIDP, its use would have been limited to that profile and its supersets.
Because, just like profiles and configurations, optional packages are specified through the Java Community Process, each has its own reference implementation (RI) and test compatibility toolkit (TCK). Besides aiding the vendors in implementing optional packages as part of their runtime environments, the RI and TCK also ensure that those implementations are done consistently and correctly, no matter which device is being used.
Note that it is the vendor of a Java runtime environment – in many cases, the device manufacturer – that controls which optional packages are available, just as it controls which configuration is used and which profiles are available. In general, it's not possible to use an optional package if it's not preloaded onto a device as part of the runtime environment. It takes some time after an optional package's specification has been finalized before implementations of the package appear in commercially available devices.
For the application developer, an optional package is just another set of Java classes to place in the Java compiler's classpath. The classes are not packaged with the applications, of course, because the devices that support the optional package include them in their runtime environments.
To detect the presence or absence of an optional package, test for the existence of a class unique to the optional package:
... public static boolean isWMAPresent(){ try { Class.forName( "javax.wireless.messaging.MessageConnection" ); return true; } catch( Exception e ){ return false; } } ...
Choose the class to test with care. For example, the existence of the java.rmi.Remote interface does not imply that the RMI Optional Package (JSR 66) is supported, because the Personal Basis Profile includes the same interface as part of its support for inter-Xlet communication.
If an optional package is required for your application to function, make sure the application checks for its existence, and exits gracefully if it's not found. Letting the application terminate with a cryptic "class not found" error will confuse its user.
Several optional packages have already been defined through the Java Community Process, and more are under development. For the complete list of optional packages, refer to the JCP web site for J2ME-related JSRs. Here are brief summaries of the more interesting and important optional packages:
Remote method invocation (RMI), a feature of J2SE, enables Java objects running in one virtual machine to invoke methods of Java objects running in another virtual machine seamlessly. The RMI Optional Package (RMIOP) extends this capability to the J2ME platform. The RMIOP is a subset of J2SE 1.3's RMI functionality. It is for use in CDC-based profiles that incorporate the Foundation Profile, such as the Personal Basis Profile and the Personal Profile. The RMIOP cannot be used with CLDC-based profiles because they lack object serialization and other important features found only in CDC-based profiles.
The RMIOP supports most of the J2SE RMI functionality, including the Java Remote Method Protocol, marshalled objects, distributed garbage collection, registry-based object lookup, and network class loading. HTTP tunneling and the Java 1.1 stub protocol are not supported.
Using the RMIOP is mostly a matter of avoiding the unsupported classes and features of the full RMI specification. You can use the standard rmic tool from the J2SE Software Development Kit to generate the RMI stub classes.
You can find the RMIOP specification at the JCP site.
As I mentioned earlier, the Wireless Messaging API lets J2ME applications send and receive messages using the Short Message Service, a messaging protocol used by cellphones across the world. The WMA extends the CLDC's Generic Connection Framework (GCF) by defining a new connection interface, javax.wireless.messaging.MessageConnection, and exposing SMS and CBS connections (short for Cell Broadcast Service, a related protocol) through protocol handlers for URLs beginning with "sms:" or "cbs:". For example, here's how to send an SMS text message with the WMA:
... import javax.microedition.io.*; import javax.wireless.messaging.*; ... MessageConnection conn = null; String url = "sms://+417034967891"; try { conn = (MessageConnection) Connector.open( url ); TextMessage msg = conn.newMessage( conn.TEXT_MESSAGE ); msg.setPayloadText( "Please call me!" ); conn.send( msg ); } catch( Exception e ){ // handle errors } finally { if( conn != null ){ try { conn.close(); } catch( Exception e ){} } } ...
The WMA can be used with any J2ME profile.
The Mobile Media API (MMAPI) defines abstractions for the capture and playback of multimedia content. If a device supports the playback of specific audio or video formats, or the recording of audio or video content (such as through an integrated camera), those capabilities can be exposed generically through the MMAPI. Downloading and playing a music recording, for example, is as simple as doing this:
... import java.io.*; import javax.microedition.media.*; ... try { Player p = Manager.createPlayer( "http://somesite.com/music.mp3" ); p.start(); } catch( IOException ioe ){ } catch( MediaException me ){ } ...
The code above assumes, of course, that the device's capabilities include playing MP3-encoded streams.
The full MMAPI can be used with any J2ME profile. A subset of the MMAPI has actually been incorporated into the Mobile Information Device Profile 2.0.
Java applications communicate with relational database servers using JDBC, a feature of J2SE. The JDBC for CDC/FP optional package (JDBCOP) is a strict subset of JDBC 3.0 that excludes some of JDBC's advanced and server-oriented features, such as pooled connections and array types.
The JDBCOP is meant for use with the Foundation Profile or its supersets.
 |
联系客服
