This week two JSRs reached the final specification deliverable making them endorsed Java standards. Java Help 2.0 and the Generic Connection Framework for J2ME were ratified and released in final form. In addition, the executive committees passed the final ballots for JSRs dealing with J2EE client provisioning, the Portlet specification and JMX remoting.
Two new JSRs were proposed. The first deals with adding native bindings to the OpenGL graphics library, the other intends to provide a component based management framework to create, share and deploy mobile applications.
The existing 3D API for Java, Java 3D is a high level, scene graph based API and does not meet the needs of those who require only a low level 3D API or those already using their own scene graph structure. There is a need to have access to hardware accelerated 3D graphics from a low level 3D graphics library. OpenGL is the major platform independent, low level 3D API in the market today. Creating Java bindings to this library will meet the needs of the Java Platform for 3D graphics capabilities. This specification intends to describe the Java bindings to the native 3D graphics library, OpenGL. This will include all core GL calls as well as the GLU library. Functionality available from the wgl/glx/agl platform specific libraries will be abstracted out to create a platform independent way of selecting framebuffer attributes and performing platform specific framebuffer operations. The specification will be made device agnostic to allow for the possibility of subsetting the API for different classes of devices via future JSRs.
This JSR will be under public review until 20th October 2003. To contribute, send an email to jsr-231-comments at jcp.org.
The J2ME Connected Device Configuration offers enhanced capabilities over the J2ME Connected, Limited Device Configuration such as the capability to install new, shared libraries after manufacture and the ability to run multiple, simultaneous applications. These and other new powerful capabilities require a correspondingly powerful management environment.
The management framework described by this Specification will allow developers to create applications as simple, interoperable, sharable components that can be dynamically deployed.
This Specification will define a component management framework that will allow mobile devices based on the J2ME Connected Device Configuration to evolve and adapt their capabilities by installing new components on demand. These components can be a combination of active elements with no user interaction (services), active elements with user interfaces (applications), and shared libraries (both native and Java). The framework will enforce a predictable lifecycle model for these sharable components that will encompass install, start, stop, update, and uninstall. The framework will also provide for multiple applications to coordinate the use of single-access resources such the device display. In order to ensure a safe environment, these components will be controlled via a mandatory security model based on the Java 2 Platform security model. In order to minimize fragmentation, accelerate adoption, and reduce time to market, this Specification will reference existing standards and implementations wherever possible. In order to ensure backward compatibility this Specification will also describe how Mobile Information Device Profile 2.0 MIDlet suites will be managed.
This JSR will be under public review until 20th October 2003. To contribute, send an email to jsr-232-comments at jcp.org.
Three JSR’s were approved for further development under the guidelines of the JCP. This JSR’s were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)
The purpose of this JSR is to define the following:
- A generic optional API to initiate payment transactions
- The syntax for the description of the associated provisioning data, enabling API implementers to support different payment instruments
Both will allow 3rd party developers to build applications with control of features and services that are chargeable. The JSR API may include methods for
- Requesting payment transaction
- Requesting feature and service price management
- Payment service availability
The provisioning data definitions take care that service providers and payment service providers can select a suitable set of payment instruments provisioned for applications during the application deployment time. Primarily payment instruments addressed will be
- Operator charging
- Stored value accounts
- 3rd party payment service providers
This JSR will provide a solution to allow J2ME application developers to gain revenue at a finer grained basis controlled directly from within J2ME applications, i.e. pay per level, and pay per feature etc. rather than pay per application or pay per download. This JSR differs from JSR-182 (Payment API for the Java platform) in the following way: while JSR 229 will define an API between a mobile application and a payment facility, JSR-182 concentrates on handling of payment interactions with web-based services. Therefore, JSR-182 could be used to implement one of the payment methods as supported by this proposal (i.e. JSR-182 is one possible payment instrument).
This JSR will be a J2ME optional package to enable mobile applications to synchronize their application specific data stored in the terminal with corresponding data stored on a server (or any other target) replicating any changes made to either instance of the data. It intends to provide a generic interface to the data synchronization device implementation, to enable data synchronization via underlying implementations of data synchronization protocols. One example of the data synchronization protocols to be accessed from Java applications will be SyncML/OMA Data Synchronization.
Public Review Specifications
The following JSRs were released for public review.
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.
The expert group is working now to ensure we get as much feedback as we can during this review period. To this end, we have decided to open our community review to the public. We would really appreciate you taking the time to download and review the materials, and provide comment and feedback. Those materials can
be found at http://jcp.org/aboutJava/communityprocess/review/jsr215/index.html.
Please help make the JCP an ideal model for developing community endorsed standards by downloading, reviewing and providing feedback!
The public review of this specification ends on October 28th 2003. To contribute, send email to jsr-215-comments at sun.com. The review and supplementary materials are available at
Low–level threading primitives, such as synchronized blocks, Object.wait and Object.notify, are insufficient for many programming tasks. As a result, application programmers are often forced to implement their own higher level concurrency facilities. This results in enormous duplication of effort. Further, such facilities are notoriously hard to get right and even more difficult to optimize. The concurrency facilities written by application programmers are often incorrect or inefficient. Offering a standard set of concurrency utilities will ease the task of writing a wide variety of multithreaded applications and generally improve the quality of the applications that use them.
This JSR has aims analogous to those of the JDK1.2 Collections package:
- To standardize a simple, extensible framework that organizes commonly used utilities into a small enough package to be readily learnable by users and maintainable by developers
- To provide some high-quality implementations
The implementation will consist of interfaces and classes that tend to be useful across diverse programming styles and applications. These classes include:
- Atomic variables
- Special-purpose locks, barriers, semaphores and condition variables
- Queues and related collections designed for multithreaded use
- Thread pools and custom execution frameworks
The public review of this specification ends on December 6th 2003. To contribute, send email to jsr-166-comments at sun.com or go to http://gee.cs.oswego.edu/dl/concurrency-interest/index.html . The review is available at
These APIs will provide Java applications, system management tools and RAS–related tools with the ability to monitor the health of the Java virtual machine as well as manage certain run–time controls such as class loading, memory and garbage collection statistics, thread statistics, object references and state, operating system and platform information. It will also provide control for JIT compilation, thread creation, garbage collector operation and heap allocation. It will support JMX invocation and its feature set and implementation will be developed to in synergy with the new platform profiling architecture.
The public review of this specification ends on November 13th 2003. To contribute, send email to jsr-174-comments at sun.com. The review is available at
JSR Final Ballot Approvals
The final specifications were approved were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee). At this stage, the complete final specification is available for download along with documentation and reference implementations of the specification.
The term provisioning refers to the activities of advertising client services to a client device, and to the process of delivering the service to the device. The physical form of a client service that is delivered to a client device could take the form of an archive file containing Java byte code and the resources it uses, a file containing a screen saver, other media or other executable. This specification defines an extension to the Java 2, Enterprise Edition (J2EE) platform that is targeted at enabling J2EE application servers with facilities for building provisioning applications. The server running provisioning applications is known as a provisioning server. A provisioning server allows a variety of client devices to discover services and to have them delivered to the device. This specification defines the programming API that developers use to write provisioning applications, and a packaging format to enable seamless addition of services that the provisioning server will provision.
You may download the final specification and reference implementation from
Portlets are web components much like Servlets specifically designed to be aggregated in the context of a composite page. Usually, many Portlets are invoked to in the single request of a Portal page. Each Portlet produces a fragment of a page that it s combined with the fragments of other Portlets, composed within the Portal page. The Portlet specification will define the different components for Portal Computing, their interaction, lifecycle and semantics. These components will comprise, but they will not be restricted to: Portlets, Deployment descriptor, Portlet APIs. In addition, APIs for vendor extensions, APIs for security, user customization and layout management will be considered. The Portlet specification will be based on the Servlet specification. It is envisioned that the developer API will be similar to the Servlet API.
You may download the final specification and reference implementation from
Java Management Extensions (JMX, JSR-3) currently provides the means to create Java based management agents, through standardized techniques for instrumentation, and standardized agent services. But it does not standardize the means to access these agents remotely. There are no API’s that define a common technique to connect to and access these management agents from remote machines. This JSR intends to define a Client interface for communicating with management agents thereby exposing a single interface to the client, hiding and abstracting the underlying tunneling and messaging protocol.
You may download the final specification from
JSR Final Release
At this stage the final specification, Technology Compatibility Kit (TCK) and reference implementations are available for developers to use.
In order to support a generic mechanism of creating “connections” from small devices to other devices, networks or storage systems the Java Microedition Platform (J2ME) defines a “Generic Connection Framework” (JSR-46). This generic framework provides runtime protocol binding and an abstraction to creating connections hiding all the protocol, transport and network specific details from the application programmer. The Java Standard Platform (J2SE) support connections through a number of libraries and classes within the java.io and java.net package namespaces. This JSR intends to provide the Generic Connection Framework as implemented in J2ME to J2SE. This will allow complete and seamless portability of applications written from J2ME to J2SE.
You may download the final specification and reference implementation from
JavaHelp software is a full-featured, platform-independent, extensible help system that enables developers and authors to incorporate online help in applets, components, applications, operating systems, and devices. Authors can also use the JavaHelp software to deliver online documentation for the Web and corporate Intranet. JavaHelp 2.0 is a major update to the 1.0 specification. The updates include enhancements to merging, multi topic printing, improved secondary window and popup usage, JFC ToolTip HelpSet support, HelpSet presentation controls and additional Navigators.
You may download the final specification and reference implementation from http://jcp.org/aboutJava/communityprocess/final/jsr097/index.html
- The OpenGL 1.4: http://opengl.org/developers/documentation/specs.html
- J2ME Connected Device Configuration: http://www.jcp.org/en/jsr/detail?id=36
- J2ME Foundation Profile: http://www.jcp.org/en/jsr/detail?id=46
- The Open Mobile Alliance Device Management: http://www.openmobilealliance.org/devicemanagement.html
- Open Systems Gateway Initiative (OSGiTM) Service Platform: http://www.osgi.org/resources/spec_overview.asp
- Mobile Information Device Profile 2.0: http://www.jcp.org/en/jsr/detail?id=118
SyncML.org and Open Mobile Alliance Specifications for Data Synchronization: http://www.syncml.org
- The JCP website: http://www.jcp.org
- An excellent explanation of the JCP timeline: http://www.jcp.org/en/introduction/timeline
- Detailed information on how to participate: http://www.jcp.org/en/participation/overview
- FAQ that answers common questions on the JCP: http://www.jcp.org/en/introduction/faq
- JSR 99 (JSPA): http://www.jcp.org/en/jsr/detail?id=99
- JSR 171 (JCP 2.5): http://www.jcp.org/en/jsr/detail?id=171
- Java 2 Mobile Edition Implementation and Information: http://java.sun.com/products/j2me
- Various Portlet implementations which JSR-168 (Portlet Specification) intends to unify
- 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
- JavaHelp specifications and reference implementation: http://java.sun.com/products/javahelp/
- Doug Lea’s concurrency package: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
- The High-Performance Java Platform Computing package: http://sourceforge.net/projects/jhpc
- JthreadKit Thread libraries: http://www.jthreadkit.com/
- Java Management Extensions: http://java.sun.com/products/JavaManagement/
- Web-Based Enterprise Management (WBEM) Initiative: http://www.dmtf.org/standards/standard_wbem.php
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.