1 Developer Migration Guide

Learn the changes between version 3.4 of the Oracle Java ME Embedded and the current instance, version 8.3 , if you need to port earlier applications to the latest version of the Oracle Java ME Embedded runtime. You can safely skip this chapter, if you have not developed IMlets using version 3.4 or earlier of the Oracle Java ME Embedded platform.



Java ME 8 is an umbrella terms for two new JSRs: CLDC 8 and MEEP 8. CLDC 8 is a major evolution of CLDC 1.1, while MEEP 8 is a major evolution of IMP-NG. Java ME 8 also includes support for the new Device I/O API.

CLDC 8 is backwards compatible with CLDC 1.1, but includes alignment with the Java SE 7 and 8 language, core APIs, and VM functionality, Java SE-style class-based fine-grain permissions, as well as a significantly enhanced Generic Connection Framework (GCF).

MEEP 8 allows execution of most IMP-NG applications, and includes significant enhancements by leveraging the CLDC 8 features, improvements in the application platform, improved software provisioning and management, footprint scalability through optional APIs, improved connectivity options, and more flexible authentication and authorization mechanisms.

The Device I/O API defines an API that allows Java applications running on small embedded devices to access peripheral devices, from a peripheral device external to the host device to a peripheral chip embedded in the host device.

It is strongly recommended that developers familiarize themselves with the CLDC 8 specification and API, the MEEP 8 specification and API, and the Device I/O API.

Modified Permission Model

There are a number of new permissions that object methods must obtain before they can successfully access peripherals. These permissions are covered in more detail in Chapter 2. However, developers should be aware of the following:

  • Java ME 8 now uses Java SE-style class-based fine-grain permissions.

  • Applications should request the jdk.dio.DeviceMgmtPermission permission when accessing any devices connected to the board through protocols such as GPIO, I2C, SPI, or MMIO, in addition to the permissions required by the communication bus they are using.

  • The syntax for the permissions request has changed. The request now includes the device identifier and any specific actions that are requested, if applicable. Device identifiers (e.g., GPIO7, SPI) are listed in the appropriate appendix of the Getting Started Guide for that development board.

  • A single request cannot be used for multiple devices; each permissions must be listed separately. For example, you cannot do the following:

    MIDlet-Permission-1: jdk.dio.GPIOPinPermission "GPIO7,GPIO8" "open"

    Instead, you must do this:

    MIDlet-Permission-1: jdk.dio.GPIOPinPermission "GPIO7" "open"
    MIDlet-Permission-2: jdk.dio.GPIOPinPermission "GPIO8" "open"

    In some cases, you can use an asterisk as a wildcard.

Device I/O Namespace

The Device Access API of the Oracle Java ME Embedded platform is now referred to as the Device I/O API, and is no longer part of the com.oracle.deviceaccess package. Instead, all classes now use the jdk.dio namespace. In addition:

  • Classes that contain "Peripheral" have been changed to "Device." So, for example, PeripheralManager has been replaced by DeviceManager, and PeripheralPermission has been replaced by DevicePermission.

  • Support now exists for pulse width modulation (PWM) on all platforms.

  • Almost all of the individual class methods are unchanged.

Generic Connection Framework Changes

The IMP-NG javax.microedition classes are now replaced by the Generic Connection Framework (GCF) with JSR-360 and Java ME Embedded Profile classes (MEEP) with JSR-361. There are a large number of changes that are included in these new profiles. See the specification pages online for more information on each of these classes.