Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
|
JSRs: Java Specification Requests
JSR 197: Generic Connection Framework Optional Package for the J2SE Platform
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: The Generic Connection Framework (GCF) Optional Package for J2SE will permit applications that rely on the GCF in J2ME to migrate to J2SE. Please direct comments on this JSR to the Spec Lead(s) Team
The following information has been updated from the original proposal. 2008.09.19: Maintenance Lead: Roger Riggs, Sun Microsystems, Inc. E-Mail Address:
roger.riggs Telephone Number: +1 781 442 0539 Fax Number: +1 781 442 1610 Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Jonathan Courtney E-Mail Address: jonathan.courtney@sun.com Telephone Number: +1 408 276 7398 Fax Number: +1 408 276 7201 Specification Lead: Jonathan Courtney E-Mail Address: jonathan.courtney@sun.com Telephone Number: +1 408 276 7398 Fax Number: +1 408 276 7201 Initial Expert Group Membership: Espial Supporting this JSR: Acunia Section 2: Request
2.1 Please describe the proposed Specification:he GCF Optional Package will soley consist of the javax.microedition.io package as defined in the J2ME Foundation Profile (JSR-46) specification. As defined in the Foundation Profile, this package is a superset of the same package as defined in the J2ME Mobile Information Device Profile (MIDP, JSR-37) and the J2ME Connected, Limited Device Configuration (CLDC, JSR-30). Therefore, the GCF Optional Package will enable applications written to the javax.microedition.io APIs in any existing J2ME Profile to use these APIs in an identical manner in J2SE when the optional package is present. Since the purpose of the GCF Optional Package is to enable compatibility from J2ME to J2SE, this JSR does not propose the addition of any functionality not already provided by the J2ME Foundation Profile in the javax.microedition.io package. However, specification improvements have been added to the GCF APIs in CLDC 1.1 (JSR-139), so these will be included in the proposed optional package specification as appropriate. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Desktop and server 2.3 What need of the Java community will be addressed by the proposed specification?Upward-compatibility, from J2ME to J2SE, of applications that use the javax.microedition.io package. 2.4 Why isn't this need met by existing specifications?The APIs for the Generic Connection Framework are not supported in J2SE. 2.5 Please give a short description of the underlying technology or technologies:(Excerpted from the CLDC 1.1 specification)
Background and motivation
The Generic Connection framework A central objective of this design is to isolate, as much as possible, the differences between the use of one protocol and another into a string characterizing the type of connection. This string is the parameter to the method Connector.open. A key benefit of this approach is that the bulk of the application code stays the same regardless of the kind of connection that is used. This is different from traditional implementations, in which the abstractions and data types used in applications often change dramatically when changing from one form of communication to another. The binding of protocols to a J2ME program is done at runtime. At the implementation level, the string (up to the first occurrence of `:') that is provided as the parameter to the method Connector.open instructs the system to obtain the desired protocol implementation from a location where all the protocol implementations are stored. It is this late binding mechanism which permits a program to dynamically adapt to use different protocols at runtime. Conceptually this is identical to the relationship between application programs and device drivers on a personal computer or workstation.
Design of the Generic Connection framework
The Generic Connection framework is intended to be extensible so that additional interfaces can be added later by J2ME profiles if they require new connection types. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.io 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?No. 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.Completion within 180 days from approval of JSR. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Email and phone conferences. 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.* J2ME
Foundation Profile (JSR-46)
3.2 Explanation of how these items might be used as a starting point for the work.See section 2.1. |