Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 230: Data Sync API

Stage Access Start Finish
Proposed Final Draft Download page 22 Sep, 2006  
Public Review Ballot View results 30 May, 2006 05 Jun, 2006
Public Review Download page 08 May, 2006 05 Jun, 2006
Early Draft Review Download page 02 Dec, 2004 01 Jan, 2005
Expert Group Formation   07 Oct, 2003 07 Jun, 2004
JSR Review Ballot View results 23 Sep, 2003 06 Oct, 2003
Status: Dormant
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

Enabling J2METM applications to access native data synchronization implementation

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Jens Paetzold Oracle
Expert Group
  Aplix Corporation AT&T Esmertec AG
  iaSolution Inc. IBM Motorola
  Oracle Samsung Electronics Corporation Siemens AG
  Sun Microsystems, Inc.

This JSR has been Dormant
Reason: The Specification Lead chose to list this JSR as dormant in August 2011.

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2009.07.06: The Maintenance Lead changed to Sun Microsystems.

Specification Lead: Jens Paetzold

E-Mail Address:

Telephone Number: +49 89 46008 1248

Fax Number: -

2007.04.11: Jim Lee is the current temporarily acting Spec Lead.

Updates to the Original JSR

The following information has been updated from the original request:

2005.10.17: The Spec Lead changed from Siemens AG to BenQ Corporation.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Siemens

Name of Contact Person: Jens Paetzold

E-Mail Address:

Telephone Number: +49 89 722 58563

Fax Number: +49 89 722 35087

Specification Lead: Jens Paetzold

E-Mail Address:

Telephone Number: +49 89 722 58563

Fax Number: +49 89 722 35087

Initial Expert Group Membership:


Supporting this JSR:


Section 2: Request

2.1 Please describe the proposed Specification:

This JSR will be a J2ME optional package that can be used with the J2ME configurations CLDC and CDC. It enables applications to synchronize their application specific data stored in the terminal with corresponding data stored on a server, replicating any changes made to either instance of the data. It should provide a generic interface to the data synchronization device implementation, to enable data synchronization via underlying implementations of data synchronization protocols. One example of the data synchronization protocols to be accessed from Java applications will be SyncML / OMA Data Synchronization.
The API should be a high level API, that provides a common set of synchronization commands.

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

The API will support the configurations CLDC / CDC and the MIDP profile (Mobile Information Device Profile v2.0) using MIDlets. Nevertheless this API should be usable with any profile on top of the J2ME CLDC and CDC configurations.

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

The need of Java applications for data synchronization by using well defined Sync protocol such as SyncML Data Sync as standardized by and Open Mobile Alliance (OMA).
Enables Java Midlets using the data synchronization protocol implemented on the device to synchronize their data with data synchronization servers.

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

The current J2ME specifications do not cover synchronization.

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

The JSR uses the data synchronization frameworks already available on most mobile platforms. It focuses on the definition of a generic API that covers most of the existing implementations. For example, this enables the use of SyncML technology as standardized by and Open Mobile Alliance.

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

For new packages: javax.microedition.*
For packages adopted from J2SETM: java.*

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


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

Most data synchornization protocols already contain their own security model. As far as possible this security model should be mapped to the Java security model, with no changes in security as a design goal.

2.9 Are there any internationalization or localization issues?


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


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

It should be possible to complete this API specification in a reasonable time (12 months) since it is narrowly scoped and it will build on the previous work using vendor specific APIs and experience.

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

It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well.

2.13 Please describe how the RI and TCK will de 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.

Due to the optional package character of this request, RI and TCK will be delivered as standalone products.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Early information on license terms as defined in the JCP process: Siemens will license to all interested parties. TCK and RI will be available separately for license, independent implementations will be allowed.
TCK will be licensed free of charge for qualified not-for-profit and qualified individuals.
Commercial terms
- For TCK we will charge a single one time fee and annual maintenance fee
- For RI we will charge an initial access fee and per-unit royalty Due to the running negotiations about a general solution of the licensing terms question, this proposal is subject of changes.

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.

? and Open Mobile Alliance Specifictions for Data Synchronization version 1.1 (1.2 if available in time)
- JSR 30: Connected, Limited Device Configuration Specification (CLDC)
- JSR 118: Mobile Information Device Profile 2.0 (MIDP)

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

Due to the optional package character of the request, considerable cross references towards configurations and profiles the package is based on are expected.