For a long while, all the excitement in the Java 2 Platform, Micro Edition (J2ME) was centered on the Connected Limited Device Configuration (CLDC), released in final form in May, 2000. The first CLDC-based profile, the Mobile Information Device Profile (MIDP), followed two months later. MIDP garnered much interest in the Java community because it defined a new application model, as well as classes for user interface and persistence. In other words, it provided a complete environment for deploying and running interactive applications.
J2ME's other configuration, the Connected Device Configuration (CDC), was not finalized through the Java Community Process (JCP) until almost a year later, in March, 2001. The first CDC-based profile, the Foundation Profile (FP), was released at the same time. Unlike MIDP, however, FP does not provide classes for building interactive applications. Consequently, the CDC/FP combination has not generated as much excitement in the Java community.
Recently, however, two new CDC-based profiles were finalized. These profiles, the Personal Basis Profile (PBP) and the Personal Profile (PP), replace the PersonalJava platform, which is no longer under active development. Like PersonalJava, they provide the classes necessary for building interactive applications. This article describes the two profiles, and compares them to each other and to the PersonalJava platform.
A Common Foundation
To understand the new profiles properly, you must first understand what the Connected Device Configuration and the Foundation Profile bring to the J2ME platform, because both PBP and PP are based on the CDC/FP combination.
CDC Quick Summary
The Java runtime environment CDC (JSR 36) defines is much closer to J2SE's than the one CLDC defines. For one thing, CDC-based devices support the complete Java 2 Platform language specification and the complete Java 2 Platform virtual machine specification. For another, they include a much larger subset of the J2SE 1.3 application programming interfaces (APIs), with classes drawn from the following packages:
Note, however, that in general CDC includes only a subset of the classes in each package. For example, from the java.net package it includes only the classes related to datagram and URL handling - stream-based socket support is not part of CDC.
CDC is a superset of CLDC, so it also includes the classes in the
Foundation Profile Quick Summary
The Foundation Profile (JSR 46) mostly adds J2SE APIs omitted from CDC. In particular, FP augments the following packages:
FP also includes classes from three packages not found in CDC:
Note that FP includes the
As you can see, the CDC/FP combination defines a powerful environment for general-purpose programming. Missing, however, are the classes needed to build interactive applications.
The Personal Basis Profile
The Personal Basis Profile (JSR 129) is a superset of the Foundation Profile, with three new features:
These features enable the creation of interactive applications with well-defined lifecycles.
To support its new features, PBP includes subsets of the following J2SE 1.3 packages in addition to those already in CDC/FP:
Note that PBP does not support RMI: The
The Xlet Application Model
The traditional Java application model is quite simple: load a class, invoke its main() method, and wait until all non-background threads terminate or
PBP defines its own application model, similar in many ways to the MIDlet model. The Xlet model has been borrowed from the Java TV API, where it's used to control application lifecycles in set-top boxes. The model's two key elements are the
More details on Xlets and PBP can be found in these articles:
Note that PBP supports the traditional application model as well as the Xlet model.
The AWT Subset
Unlike MIDP, PBP does not define an entirely new set of user-interface classes, but instead subsets the standard AWT classes. Developers experienced in writing interactive J2SE applications will find PBP (and, as you'll see, the Personal Profile), a much more familiar environment than MIDP.
The classes in PBP's AWT subset are those required to define and use lightweight user-interface components. Originally, AWT consisted of heavyweight components, where each component instance was really just a proxy for a UI component (called a peer component) native to the underlying operating system. An application built with heavyweight components looks and feels like any other application on that platform, but the Java runtime has limited control over user-interface behavior or appearance. Java 1.1 therefore introduced the concept of lightweight components, whose look and feel are entirely under the runtime's control. There are no peer components in the lightweight model, except for top-level windows, as each component draws itself directly in its parent's drawing area and responds only to the events delegated by the parent. Top-level windows are normally heavyweight components, however, because the runtime system needs a way to interact with the operating system.
To support lightweight components, PBP specifically includes:
These are the core component classes required to build a complete user interface. Component and Container are used to create lightweight components, while Window and Frame are used to create the top-level windows that hold the lightweight components. All the other AWT classes in PBP are included to support these four.
Note that PBP specifically excludes all heavyweight components other than Window and Frame. There are no buttons, lists, menus, or other basic user-interface components. In J2SE, the lightweight versions of these basic components are defined by the Swing user-interface toolkit, but Swing is not included in the PBP.
If the heavyweight components are missing and Swing is unavailable, you might wonder how you create a user interface. There are two possibilities.
If your application is simple enough, you can create your own components:
At runtime, place these components directly on a Frame component:
An application running under the new Xlet model uses the root container supplied by the system (available through the
The second way to create user interfaces is to use third-party lightweight user-interface toolkits. These toolkits may also be augmented by vendor-supplied classes.
Besides the lack of heavyweight components, the PBP AWT subset includes specific restrictions on what an application's user interface can do, so that PBP applications can run on systems with relatively limited UI capabilities. The most important restriction is that applications may use only a single instance of the Frame class. PBP applications built using the traditional model are responsible for creating the frame themselves. By contrast, in the Xlet model the system creates the frame on the application's behalf, and makes it (or a child container) available by way of the
Inter-Xlet Communication (IXC) allows two or more Xlets running in the same virtual machine to exchange objects and to execute code across class-loader boundaries. IXC is based on the Remote Method Invocation (RMI) capabilities of J2SE, although the latter is actually meant for communication within a VM rather than between VMs. It's important to remember that by itself inter-Xlet communication does not imply that full RMI capabilities are available. To perform RMI in a PBP application, you must use RMIOP.
An Xlet can use the IXC registry to make an object available for use by other Xlets. This is known as binding or exporting the object. All Xlets share the same registry, a singleton instance of the javax.microedition.xlet.ixc.IxcRegistry class. The
The registry is like a shared hash table. An Xlet binds a name to the object using the
Other Xlets find a bound object using the
Here's a sample application that uses IXC to ensure that two or more instances of the application don't run simultaneously:
Note that classes are not loaded remotely using IXC. Although the stubs are generated automatically, the actual interfaces that those stubs implement must already be packaged with the application.
The Personal Profile
The Personal Profile (JSR 62) is a superset of the Personal Basis Profile that adds the following features:
As you can see, PP provides an even richer, more J2SE-like environment, as well as offering the new PBP features like the Xlet application model and inter-Xlet communication.
To the classes of PBP, PP adds classes from three J2SE 1.3 packages:
Unlike PBP, the Personal Profile defines no additional non-J2SE classes.
The applet model is another alternative to the traditional and Xlet application models that PBP supports. Applets are browser-based applications that run in a controlled environment (often referred to as a sandbox) created by a web browser. Like MIDlets and Xlets, applets are notified by the system when they should be started, paused, or stopped, generally in response to events like the user moving from one web page to another with the browser. For more information on applets, see The Xlet Application Model. The applet support in PP is essentially the same as provided since version 1.1 of Java and should be familiar to most readers.
The AWT Subset
Unlike PBP's AWT subset, PP's includes support for the standard heavyweight UI components, classes like
PP includes most of the AWT classes in J2SE 1.3. So what's missing? The two-dimensional graphics classes (like
The Personal Profile relaxes some of the user-interface restrictions imposed by the Personal Basis Profile. In particular, PP does not restrict the number of frames or dialogs that an application creates. The system is free to restrict the size, state, or position of top-level windows, however, as before. Again, these restrictions are to support systems with more limited UI capabilities.
Migrating from PersonalJava
Applications written to the PersonalJava specification have a J2ME migration path to the Personal Profile (or, in some cases, the Personal Basis Profile). The migration is not seamless, because there are differences between the two Java environments. For an experienced Java programmer, however, the transition is not hard to make, and you end up with an application that uses the more familiar J2SE 1.3 APIs instead of the older (now quite dated) Java 1.1 APIs.
The following packages defined by the PersonalJava 1.2a specification are the same as, or subsets of, the packages of the same name in the Personal Profile:
If your PersonalJava application limits itself to using the packages listed above (including
The other packages included in PersonalJava are not found in their entirety in the Personal Profile. In particular:
These differences are the reasons that the transition from PersonalJava to the Personal Profile may not be seamless. Some of the changes are quite minor, though. For example, no method in the Personal Profile will throw
As you can see, both the Personal Basis Profile and the Personal Profile provide complete environments for building interactive Java applications on devices that are too constrained to support full J2SE implementations. They also provide a migration path for PersonalJava applications to the Java 2 Platform.
For more information on these profiles, see the Personal Profile section of the Wireless Java portal.
Back To Top