The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 75

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2015年06月01日:

The Maintenance Lead from IBM changed to:

Maintenance Lead: Kazuhiro Konno

E-Mail Address: KONNO@jp.ibm.com

2005年10月19日:

The Maintenance Lead from PalmSource changed to:

Maintenance Lead: Tom Chavez

E-Mail Address: tom.chavez@palmsource.com

---

Submitting Member: PalmSource, Inc.

Name of Contact Person: Brad Jarvinen

E-Mail Address: brad.jarvinen@palmsource.com

Telephone Number: +1 408 400 1647

Fax Number: +1 408 400 1500

(Please note the current Maintenance Leads, above.)

Specification Lead: Brad Jarvinen

E-Mail Address: brad.jarvinen@palmsource.com

Telephone Number: +1 408 400 1647

Fax Number: +1 408 400 1500

2.1 Please describe the proposed Specification:

This specification will define two indepent optional packages that will extend and enhance the "J2ME Connected, Limited Device Configuration" JSR-000030. These packages separately represent important features found on many PDAs and other mobile devices. The optional packages are:

- Personal Information Management (PIM) - This package gives J2ME devices access to personal information management data that resides natively on mobile devices. Information to be accessed are contained in address books, calendars, and to-do lists residing in many mobile devices.
- FileConnection (FC) - This package gives J2ME devices access to file systems residing on mobile devices. The primary use of this API is to allow access to removeable storage devices, such as externable memory cards that many of today's devices support.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2ME, Connected Limited Device Configuration 1.0, as defined by JSR-000030, is the minimum required platform. Any platform supported at least the APIs defined in CLDC 1.0 can include these optional packages.

2.3 What need of the Java community will be addressed by the proposed specification?

There currently is no standard API in the CLDC space that allows access to either the PIM data or to file systems.

2.4 Why isn't this need met by existing specifications?

JavaPhone exists for accessing PIM on CDC based configurations, but is inadequate and inefficient for the CLDC space. Similarly, java.io.File exists in CDC, but is too heavyweight and does not use the efficiencies surrounding the Generic Connection Framework (GCF) that the FileConnection package will be using.

2.5 Please give a short description of the underlying technology or technologies:

The PIM APIs will provide access to the native PIM databases residing on most mobile devices. The FileConnection APIs will provide GCF access to removeable storage devices and memory cards common on many mobile devices.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.microedition.pim will be the Java package for the PIM APIs. The FileConnection APIs will exist within the existing javax.microedition.io package as all other GCF protocols do.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

The PIM APIs should be deployed on devices that have native PIM databases, but is not a hard requirement. Similary, the FileConnection APIs should be deployed on devices that have access to file systems, but is also not a hard requirement.

2.8 Are there any security issues that cannot be addressed by the current security model?

As optional packages, these APIs will rely on and require the profile and/or configuration that the package is deployed on to provide support for the security requirements outlined in the packages. For instance, the PIM APIs will require that the profile and/or configuration provide support for limiting the access to the PIM data in read-only, write-only, and read-write modes.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No specifications within the CLDC realm will be rendered obsolete or deprecated as a result of these APIs.

2.11 Please describe the anticipated schedule for the development of this specification.

Feb 2003 - Proposed Final Draft
March 2003 - Final Approval Ballot Submission
April 2003 - Final Release

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The existing JSR 75 expert group will remain in place for these optional packages with no new members accepted at this time. Email is the primary medium for discussion.

2.13 Please describe how the RI and TCK will be delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

For the PIM: The PIM APIs will be a completely independent optional package, licensable separately from the FileConnection APIs. Licensees may either license the RI and TCK together, or the TCK separately. The RI will be based on CLDC 1.0 and delivered on a PalmOS emulator.
For the PIM: The FileConnecton APIs will also be a completely independent optional package, licensable separately from the PIM APIs. Licensees may either license the RI and TCK together, or the TCK separately. The RI will be based on CLDC 1.0 and delivered on a PalmOS emulator.

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

J2ME Connected, Limited Device Configuration

3.2 Explanation of how these items might be used as a starting point for the work.

CLDC 1.0 is the minimum set of APIs that these optional packages each rely on.

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: This JSR will produce optional packages for features that are commonly found on PDAs and other mobile devices in the J2ME space: one package for Personal Information Management (PIM) access, and one package for accessing file systems through the Generic Connection Framework (GCF).

Section 1. Identification

Submitting Member: Palm, Inc.

Name of Contact Person: Dan Podwall

E-Mail Address: Dan_Podwall@palm.com

Telephone Number: 1 512 514 6067

Fax Number: 1 512 514 6015

Specification Lead: Dan Podwall

E-Mail Address: Dan_Podwall@palm.com

Telephone Number: 1 512 514 6067

Fax Number: 1 512 514 6015

Note that this information has been updated since the original JSR.

Initial Expert Group Membership:

Palm, Inc.
Research In Motion
Zucotto Systems, Inc.
Stefan Haustein (kAWT)

Section 2: Request

2.1 Please describe the proposed Specification:

Under the new Java 2[tm] Micro Edition (J2ME[tm]) technology, two notions have been introduced: a configuration, and a profile. A configuration is defined as the combination of a Virtual Machine (VM) and "core" APIs that represent an underlying development platform for a broad class of devices. A profile is defined as a set of APIs for a specific vertical market and relies upon an underlying configuration's capabilities to create new, market-specifc APIs.

This specification will define a profile that will extend and enhance the "J2ME Connected, Limited Device Configuration" JSR-000030. By building upon this configuration, this profile will provide a standard platform for small, resource-limited, handheld mobile information devices characterized as follows:

• No less than 512KB total memory (ROM + RAM) available for Java runtime and libraries, and no more than 16 MB.
• Limited power, typically battery operated.
• User interfaces of varying degrees of sophistication, but having at least: displays with a total resolution of at least 20,000 pixels, a pointing device, and character input.

This profile, in conjunction with the "J2ME Connected, Limited Device Configuration", will enable application development for handheld devices used as personal digital assistants.

Wherever possible, this profile will utilize the core functionality provided by the "J2ME Connected, Limited Device Configuration." Potential APIs that will need to be created, extended, or enhanced include the following:

• A display toolkit suitable for limited size and depth displays. In order to support the existing base of developer expertise, this toolkit will be a subset of the Abstract Window Toolkit.
• Simple persistent data storage for applications, data, and configuration information.

Note that this information has been updated since the original JSR.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2ME, Connected Limited Device Configuration as defined by JSR-000030

Note that this information has been updated since the original JSR.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification will create a new standard API for PDA devices running the J2ME Connected, Limited Device Configuration.

Note that this information has been updated since the original JSR.

2.4 Why isn't this need met by existing specifications?

Existing APIs are either appropriate for smaller devices, or are predicated on the capabilities and memory requirements of larger JVMs such as EmbeddedJava and Personal Java. An example of the former type of API is the MID Profile; an example of the latter is Java Phone.

Note that this information has been updated since the original JSR.

2.5 Please give a short description of the underlying technology or technologies:

See section 2.1 for expected underlying device technologies.

Note that this information has been updated since the original JSR.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

None identified at this time.

Note that this information has been updated since the original JSR.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

None identified at this time.

Note that this information has been updated since the original JSR.

2.8 Are there any security issues that cannot be addressed by the current security model?

Due to the class of devices addressed by this specification, it is expected that existing security models will be too heavy weight; therefore, they will have to either be lightened or reworked; however, wherever possible, this specification will rely upon features of the J2ME Connected, Limited Device Configuration.

Note that this information has been updated since the original JSR.

2.9 Are there any internationalization or localization issues?

Wherever possible, this specification will rely upon features of the J2ME Connected, Limited Device Configuration to implement internationalization and localization.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

None identified at this time.

Note that this information has been updated since the original JSR.

2.11 Please describe the anticipated schedule for the development of this specification.

We plan to begin the community review by the end of 2000.

Note that this information has been updated since the original JSR.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Note that this information has been updated since the original JSR.

• J2ME Connected, Limited Device Configuration
• the Abstract Window Toolkit
• Mobile Information Device Profile for J2ME

3.2 Explanation of how these items might be used as a starting point for the work.

Note that this information has been updated since the original JSR.

The profile will be based on CLDC and AWT. It will use simple, platform-independent persistent data storage similar to what was prototyped for the FCS version of the CLDC and what was described in the Mobile Information Device Profile for J2ME. In order to conserve memory on constrained devices, in-place read and write access to data records will be investigated. The profile may include the MIDP user interface components layered on top of the AWT subset.