The JCP Executive Committee for the Java 2 Mobile Edition platform (J2ME) rejected the proposed specifications involving Java 1.4 updates and enhancements to the core specifications governing J2ME. In addition, there were proposed final drafts for the J2ME Information Module Profile and the JAIN MEGACO API's. Finally, public review specifications have become available for the Wireless Messaging API's, Mobile 3D graphics and XML Digital Signature API's
Approved JSR's
Both Standard Edition and Mobile Edition Committees unanimously approved the specification involving changes to the Java Community Process for further development under the guidelines of the JCP. These JSR's were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)
This JSR aims to define a new version of the Java Community Process to address some of the day-to-day issues of Spec Leads and Expert Groups through relatively minor, easy to implement changes to the process. None of the changes require modification to the participation agreements (the JSPA or IEPA). This JSR will not consider any issues that are difficult to implement or that require changes to the JSPA.
In particular this JSR will address the following issues:
- Some JSRs may need to span Editions and therefore span the Executive Committees. This JSR will consider defining when that is possible, and how that works.
- JSRs should be more transparent to the community, and it should be easier to tell when a JSR is working and when it is dormant. This JSR will consider requiring Spec Leads to provide a status report to the PMO on a regular basis, which would be posted to the web site for community member viewing.
- There is value to the Spec Leads to have two classes of Expert Group members - active members and observers. This JSR will consider ways to enable observer memberships to Expert Groups.
- This JSR would also consider giving Executive Committee members the right to assign a member as an observer to the expert group for any JSR that is assigned to the Executive Committee on which they serve.
- There is a mistake in the process document with regards to super-majority voting. This JSR would change the process from requiring super majority ballots to J2SE umbrella JSRs that propose language changes to requiring super majority ballots on any JSRs that propose language changes.
- In order to promote more feedback at the review periods, this JSR will consider changing Community Review to Early Draft Review and making it open to the public. Also, this JSR will consider removing the Community Review Ballot and replacing it with a ballot after the second public review, called Public Review Ballot.
- This JSR will consider setting minimum requirements for Technology Compatibility Kits (TCK).
- This JSR will also consider requiring spec leads to deliver a TCK Coverage Document that will enable Executive Committee members to judge the sufficiency of a TCK.
- This JSR will consider moving the disclosure of TCK and other business terms to a point earlier in the process.
Rejected JSRs
The JCP Expert group for J2ME rejected the following specifications governing updating the existing core J2ME specifications to add support for new features and functionality found in J2SE 1.4. The following set of JSR's were rejected:
The Executive Committee members cited a number of reasons for rejection of these proposals among which are:
- The increase in ROM size for devices specified in the JSR's is significantly greater than acceptable in the targeted spaces, making this fairly impossible to attain acceptance among device manufacturers.
- There is no evidence of the J2ME platform requiring the new functionality and features offered by Java 1.4.
- Such sweeping changes to the underlying platform should be made only if there is a significant demand, otherwise it should be specified as an optional package to the core specifications.
- Licensing model proposed for the Reference Implementation and Technology Compatibility Kit seems to be limited and not in the spirit of Open Source.
You can find a more detailed description of these JSR's in my previous installment at http://www.developer.com/java/other/article.php/2203411.
Community Review
One JSR released a specification for members of the JCP. This JSR deals with the emerging standards for the set of APIs that relate to converged Internet (data) and telephony (voice) networks called JAIN.
Java Coordination and Transaction (JCAT) includes (but is not limited to) the facilities required for applications to be invoked and return results before, during or after calls; to process call parameters or subscriber-supplied information; and to engage in further call processing and control. The JCAT JSR will extend another JAIN API called Java Call Control (JCC) which provides the facilities required for observing, initiating, answering, processing and manipulating calls, where a call is understood to include (but is not necessarily limited to) a multimedia, multiparty session over the underlying integrated (PSTN, packet and/or wireless) network. JCAT will extend JCC with concepts to model and control terminal capabilities. This enriches JCC's state transitions models by giving more control over its processing.
The Community review closes on 14th July 2003. JCP members may access the Community review at http://java.sun.com/aboutJava/communityprocess/participant/jsr122/index.html.
Public Review Specifications
This JSR is to define a standard set of APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, the XML Digital Signature specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. The XML Digital Signature specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.
The Public review closes on 29th June 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr105/index.html.
This JSR intends to extend the existing wireless messaging API's (JSR-120) to support Multimedia Message Service (MMS), which would allow Java mobile applications to create, send and receive rich media messages containing text, graphics, animations, audio and video.
The Public review closes on 3rd July 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr205/index.html.
This JSR was described in more detail in my previous installment at http://www.developer.com/java/other/article.php/1583471.
This proposed JSR will provide a scalable, small-footprint, interactive 3D API for use on mobile devices.
The Public review closes on 12th June 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr184/index.html
Proposed Final Draft Specifications
Also see http://jcp.org/aboutJava/communityprocess/first/jsr195/index.html. This JSR will define a J2ME profile targeting embedded networked devices that wish to support a Java runtime environment similar to the Mobile Information Device Profile (MIDP) version 1.0, but that do not provide the graphical display capabilities required by MIDP 1.0. The Information Module Profile (IMP) will be a strict subset of MIDP 1.0, where the APIs relating to GUI functionality (the LCDUI) are simply removed. Functionality not already present in MIDP 1.0 is not anticipated or desired.
Also see http://jcp.org/aboutJava/communityprocess/first/jsr79/index.html.
The MEGACO/H.248 is a new protocol belonging to the Gateway Control class of Protocols. It is a protocol proposed jointly by IETF and ITU-T that specifies the syntax and semantics of messages that are used by the Call Agent to control and thereby establish media connections in a Gateway. The protocol defines a model for the Gateway comprising objects called as Contexts and Terminations and defines APIs by which the Call Agent can manipulate these objects within the Gateway. This JSR intends to implement the JAIN APIs for the MEGACO protocol.
Resources
What do you think of the JCP? What do you think of the current JSR's? Do you have any suggestions for this column? Feel free to write to me at apu at jcpwatch.org.
IE 7
Firefox 2.0
