Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 197: Generic Connection Framework Optional Package for the J2SE Platform

Updates to Original JSR

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@sun.com

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
IBM
Motorola
ProSyst
Sun Microsystems
Telcordia

Supporting this JSR:

Acunia
aQute
Echelon
Gatespace
OSGi Alliance
Philips
T-Systems



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 class libraries included in Java 2 Standard Edition and Java 2 Enterprise Edition provide a rich set of functionality for handling input and output access to storage and networking systems. The package java.io.* of J2SE contains approximately 60 classes and interfaces, and more than 15 exception classes. The package java.net.* of J2SE consists of approximately 20 regular classes and 10 exception classes. It is difficult to make all this functionality fit in a small device with only a few hundred kilobytes of total memory budget. Furthermore, a significant part of the standard I/O and networking functionality is not directly applicable to today's small devices, which do not often provide TCP/IP support, of which often need to support specific types of connections such as IrDA (infrared) or Bluetooth. In general, the requirements for the networking and storage libraries vary significantly from one resource-constrained device to another. For instance, those device manufacturers who use packet-switched networks typically want datagram-based communication mechanisms, while those using circuit-switched networks commonly prefer stream-based connections. Some of the devices have traditional file systems, while many others have highly device-specific mechanisms. Due to strict memory limitations, manufacturers supporting certain kinds of input/output, networking and storage capabilities generally do not want to support other mechanisms. All this makes the design of these facilities for CLDC very challenging, especially since J2ME configurations are not allowed to define optional features. Also, the presence of multiple networking mechanisms and protocols is potentially very confusing to the application programmer, especially if the programmer has to deal with low-level protocol issues.

The Generic Connection framework
The challenges presented above led to the generalization of the J2SE network and I/O classes. The general goal for this generalized design is to be a functional subset of J2SE classes, which can easily map to common low-level hardware or to any J2SE implementation, but with better extensibility, flexibility and coherence in supporting new devices and protocols.

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
Connections to different types of devices will need to exhibit different forms of behavior. A file, for instance, can be renamed, but no similar operation exists for a TCP/IP socket. The Generic Connection framework reflects these different capabilities, ensuring that operations that are logically the same share the same API. The Generic Connection framework is implemented using a hierarchy of Connection interfaces (located in package javax.microedition.io) that group together classes of protocols with the same semantics. This hierarchy consists of seven interfaces. Additionally, there is the Connector class, one exception class, one other interface, and a number of data stream classes for reading and writing data. At the implementation level, a minimum of one class is needed for implementing each supported protocol. Often, each protocol implementation class contains simply a number of wrapper functions that call the native functions of the underlying host operating system.
There are six basic interface types that are addressed by the Generic Connection framework:

  • A basic serial input connection
  • A basic serial output connection
  • A datagram oriented connection
  • A circuit oriented connection
  • A notification mechanism to inform a server of client-server connections
  • A basic Web server connection
The collection of Connection interfaces forms a hierarchy that becomes progressively more capable as the hierarchy progresses from the root Connection interface. This arrangement allows J2ME profile designers or application programmers to choose the optimal level of cross-protocol portability for the libraries and applications they are designing.
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)
J2ME Mobile Information Device Profile (JSR-37)
J2ME Connected, Limited Device Configuration (JSR-30)
J2ME Connected, Limited Device Configuration 1.1 (JSR-139)

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

See section 2.1.