Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 118: Mobile Information Device Profile 2.0

Updates to the Original JSR

The following information was updated from the original request.

2013.04.15: The JCP Member acting as Maintenance Lead has changed from Aplix to Oracle.

Maintenance Lead: Volker Bauche

E-Mail Address: volker.bauche@oracle.com

Telephone Number: +49 172 8187214

Fax Number: +49 5523 408096

2012.10.18: The person acting as Maintenance Lead has changed.

Maintenance Lead: Yagamy Huang

E-Mail Address: yagamy@aplix.co.jp

Telephone Number: -

Fax Number: -

2012.08.24: The person acting as Maintenance Lead has changed.

Maintenance Lead: Lakshmi Dontamsetti

E-Mail Address: lakshmi@aplixcorp.com

Telephone Number: -

Fax Number: -

2009.06.01:
The Maintenance Lead changed from Motorola to Aplix Corporation.

Maintenance Leads: Paul Su

E-Mail Address: paulsu@aplixcorp.com

Telephone Number: -

Fax Number: -

2006.09.18:

Maintenance Leads: Mike Milikich, James Warden

E-Mail Address: mike.milikich@motorola.com, james.warden@motorola.com

Telephone Number: +1 512 996 4216, +1 817 245 6258

Fax Number: +1 512 895 3798, +1 817 245 7628

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Motorola

Name of Contact Person: Mark VandenBrink

E-Mail Address: mark.vandenbrink@motorola.com

Telephone Number: +1 512 895 6064

Fax Number: +1 512 895 3798


NOTE that this information has been updated from this original request.

Specification Lead: Jim Van Peursem

E-Mail Address: jim.van.peursem@motorola.com

Telephone Number:

Fax Number:


Initial Expert Group Membership:

  • Motorola
  • Sun
  • Nokia



    • Section 2: Request

    2.1 Please describe the proposed Specification:

    The primary focus of the MIDP_NG specification scope will address:

    • Backward compatibility with MIDP 1.0
    • Continued focus on small, high-volume wireless phones
    • Maintain tight footprint objectives to limit growth in the core APIs
    • Information learned from MIDP 1.0 deployments to fine tune MIDP 1.0 APIs
    • Focus on core functions needed by all devices and applications
    • Focus on enabling mCommerce, service-based applications

    Functional areas to be investigated:

    • Domain security model, including signing of applications and verification of certificates
    • HTTPS and secure networking
    • Network connectivity via sockets and datagrams
    • Formal inclusion of OTA Provisioning (i.e., Recommended Practice 1 for MIDP 1.0)
    • Push architecture: external events and messages routed to appropriate MIDlets
    • User Interface - extensions to low-level LCDUI to allow greater game functionality and layout control for larger screen sizes.
    • A small, efficient XML parser to enable platform-independent data exchange
    • Base sound API

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

    J2METM

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

    In order to broadly deploy MIDP application/services, a common framework needs to be established on the phone to allow carriers/operators to design their backend systems.

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

    The CLDC and MIDP specifications to not cover the actual deployment of applications. In addition, this JSR includes some APIs that were not practical to release in the MIDP 1.0 specification due to market constraints, etc.

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

    J2METM
    CLDC 1.0
    MIDP 1.0

    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 J2SE TM: java.*

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

    No.

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

    Possibly. The Expert Group will investigate the feasibility of extending the CLDC/MIDP security models.

    2.9 Are there any internationalization or localization issues?

    No.

    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.

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

    Q1--Q2, 2002

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

    This group will operate along similar lines to the MIDP 1.0 Expert Group. Meetings will be held roughly every 8-10 weeks, and a formal mailing list will be set up. There will be a web-site set up to facilitate communication. Decisions will be made by technical consensus.





    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.

    N/A

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

    N/A