In order to increase transparency and efficiency, a JSR proposing changes in the JCP process has been submitted. Core specifications governing the Java 2 Mobile Platform (J2ME) have also been updated to take advantage of new features and API’s provided by Java 1.4. Further, the Executive Committee for the J2ME platform has rejected 2 JSR’s citing lack of developer demand, overlap with related JSR’s and potential conflict with related standards.
There were 5 new JSR’s this week of which 4 were updates to some of the core specifications defining the J2ME platform and the other was the proposal for JCP 2.6 (we are currently on JCP 2.5).
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.
This JSR will be under public review until 12th May 2003. To contribute, send an email to jsr-215-comments at jcp.org.
The J2ME CDC is a fully operational Java Virtual Machine and a set of core Java class libraries aimed at running on the higher range of electronic devices such as set-top boxes, home gateways and high end PDA’s. These devices typically have 512K minimum ROM and 256K minimum RAM available, network connectivity and user interfaces with varying degrees of sophistication down to and including none. The original JSR defining CDC 1.0 (JSR-36 J2ME Connected Device Configuration: http://jcp.org/en/jsr/detail?id=36) does not include certain J2SE, v1.4.1 features that are required by device manufacturers and application developers. This JSR intends to add new features (APIs) from J2SE, v1.4 on top of the existing J2ME CDC 1.0 set of APIs. While new APIs may be adopted from J2SE 1.4, no new, non-J2SE APIs are planned for definition in this JSR. J2ME CDC 1.1 will be backward compatible with J2ME CDC 1.0.
This JSR will be under public review until 18th May 2003. To contribute, send an email to jsr-218-comments at jcp.org.
The CDC provides a specific class (configuration) of devices with a low level Java execution environment. However in order to provide a complete Java runtime environment, the CDC is combined with a higher level set of API’s called profiles that provide the core language, networking and I/O capability and further define the application life cycle, user interface API’s for the device and allows access to device properties. These profiles are specific to each class of device. The base profile on which all other profiles are based is known as the Foundation Profile which provides a set of API’s for Java applications running on devices supporting the CDC with basic networking capabilities. The foundation profile does not provide any User Interface libraries, rather other profiles that require such functionality are expected to be implemented on top of the Foundation Profile. The original JSR describing the Foundation Profile (JSR-46 J2ME Foundation Profile http://jcp.org/en/jsr/detail?id=46) does not include certain J2SE, v1.4.1 features that are required by device manufacturers and application developers. This JSR intends to provide updates based on J2SE v1.4.1 to the existing core, non-graphical Java APIs for small electronic devices.
This JSR will be under public review until 12th May 2003. To contribute, send an email to jsr-219-comments at jcp.org.
Personal Profile provides core graphics, UI, and application model facilities on top of the J2ME Foundation Profile. The graphics and UI facilities are well known and derived from J2SE — namely, the Abstract Windowing Toolkit (AWT) and portions of Java 2D. This Profile also provides the Xlet application model, which is unique to J2ME. The original JSR describing the Personal Profile 1.0 (JSR-62: Personal Profile 1.0 http://jcp.org/en/jsr/detail?id=62) was derived from the J2SE 1.3.1 API specification. Since that time, J2SE 1.4 has provided a number of specification improvements and fixes. Additionally, the Advanced Graphics and UI (AGUI) Optional Package for J2ME (JSR-209) will require underlying platform support not present in version 1.0 of this Profile. The version 1.1 update of this Profile will provide the necessary support for the AGUI Optional Package and the latest J2SE 1.4 APIs.
This JSR will be under public review until 12th May 2003. To contribute, send an email to jsr-216-comments at jcp.org.
The Personal Basis Profile is a subset of the Personal Profile and provides an environment for applications that require basic graphical and user interface capabilities or for those devices that require specialized graphics toolkits. The Personal Profile is distinguished from Personal Basis Profile in that the Personal Profile provides the API facilities necessary for the execution of common Java web applets. Such applets make use of the applet application model and circa JDK 1.1 AWT heavyweight widget APIs. Both of these features are omitted from Personal Basis Profile; instead, it contains the AWT component framework APIs necessary for the support of lightweight widget toolkits such as Swing. The original JSR describing the Personal Basis Profile 1.0 (JSR-129: Personal Basis Profile 1.0 http://jcp.org/en/jsr/detail?id=129) was derived from the J2SE 1.3.1 API specification. Since that time, J2SE 1.4 has provided a number of specification improvements and fixes. Additionally, the Advanced Graphics and UI (AGUI) Optional Package for J2ME (JSR-209) will require underlying platform support not present in version 1.0 of this Profile. The version 1.1 update of this Profile will provide the necessary support for the AGUI Optional Package and the latest J2SE 1.4 APIs.
This JSR will be under public review until 12th May 2003. To contribute, send an email to jsr-217-comments at jcp.org.
This JSR proposing to add API’s for Java applications on top of J2SE/J2EE to compose, send and receive short messages and multimedia messages has been approved. This JSR has been covered in a previous installment available at http://www.developer.com/java/other/article.php/2196541
The Executive Committee for the J2ME platform rejected the following JSRs:
The intent of this JSR is Micro WSCI achieves this by defining a layer on top of the existing J2ME Web Service stack. This layer implements the required ‘observable’ behavior of a choreographed Web Service on the J2ME Device, relative to the message exchange it must support.
The ballot of the executive committee consisted of 11 votes not in favor, 3 abstains and 2 did not vote. The committee members cited reasons for rejection as lack of developer community demand and overlaps with JSR-172 J2ME Web Services Specification.
The goal of this JSR is to provide a standard set of APIs for representing and manipulating Collaboration Profile and Agreement information described by ebXML CPPA (Collaboration Protocol Profile/Agreement) documents on J2ME Devices. These APIs will define a way to construct and manipulate various profile information corresponding to the CPP/A.
The ballot of the executive committee consisted of 12 votes not in favor, 2 abstains and 2 did not vote. The committee members cited reasons for rejection as lack of developer need and lack of progress on JSR 157 (ebXML CPP/A APIs for Java), which questions whether similar support need be added to the mobile platform.
Public Review Specifications
Session Initiation Protocol (SIP) is an upcoming standard for establishing sessions over an IP networks. SIP is a signaling protocol similar to tone based dialing on telephone networks. SIP specifies how to establish, maintain and terminate a simple two-way telephone call or a collaborative multi-media conference session over an IP network. The goal of this JSR is to provide an API that allows SIP protocol handling for the Java Microedition enabling SIP support for small devices.
The Public review closes on 29th May 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr180/index.html
The way in which we interact with web-based services is through a browser of some sort. The browser may be on my desktop, on my PDA or on my mobile phone. I may also choose to render all the characters in a particular font. Web servers that produce the data we interact with often tailor the information suitable for the device on which it is going to be displayed. Composite Capability / Preferences Profile (CC/PP) describes the “delivery context” of data that is served by a web application. CC/PP is a W3C standard. This specification intends to implement a set of APIs for processing delivery context information allowing developers to write device independent code that can deliver tailored content to a multitude of web clients.
The Public review closes on 7th June 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr188/index.html.
A maintenance release of JSR-120 Wireless Messaging API (http://jcp.org/aboutJava/communityprocess/final/jsr120/index2.html) and an updated community draft for JSR 168 Portlet Specification (http://jcp.org/en/jsr/detail?id=168) were also released.
- JetSpeed Portlet API:http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/portletAPI/
- BEA: Web Logic Portal 4.0:http://www.bea.com/products/weblogic/portal/index.shtml
- IBM: WebSphere Portal 2.1:http://www-4.ibm.com/software/webservers/portal/
- iPlanet: iPlanet Portal Server 3.0:http://www.iplanet.com/products/iplanet_portal/home_portal.html
- Oracle: Oracle 9i Portal:http://www.oracle.com/ip/deploy/ias/portal/index.html
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.