The Location API for J2ME which provides an interface to positioning systems like GPS was approved in it’s final ballot making it an endorsed Java standard. Further, proposed final draft specifications for XML Streaming API‘s, Java OLAP and Portlets were released. New JSR’s relating to data synchronization and mobile payments were also proposed.
Two new JSR’s were proposed for the J2ME platform.
The purpose of this JSR is to define the following:
- A generic optional API to initiate payment transactions and
- In addition 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 under public review until 6th October 2003. To contribute, send an email to jsr-229-comments at jcp.org.
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.
This JSR will be under public review until 6th October 2003. To contribute, send an email to jsr-230-comments at jcp.org.
One JSR‘s was 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)
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 2.0, but that do not provide the graphical display capabilities required by MIDP 2.0. The Information Module Profile – Next Generation (IMP-NG) will be a strict subset of MIDP 2.0, where at least the APIs relating to GUI functionality (the LCDUI) are removed. Functionality not already present in MIDP 2.0 is not anticipated or desired.
The primary focus of this “IMP–NG” specification scope will address:
- Backward compatibility with IMP
- Maintain tight footprint objectives to limit growth in the core APIs
- Overtake all functional areas from MIDP 2.0, which are useful for embedded networked devices, on particular
- The domain security model, including signing of applications and verification of certificates
- HTTPS and secure networking
- Network connectivity via sockets and datagrams
- OTA Provisioning
- Push architecture: external events and messages routed to appropriate Imlets
Public Review Specifications
The following JSR‘s were released for public review.
Java Database Connectivity (JDBC) specifies a Rowset interface which allows programmatic access to manipulate and view tabular data stored within a database. However, JDBC does not specify any proposed implementations which is what this JSR intends to provide, a guideline for implementations of the Rowset interface.
The public review of this specification ends on September 27th 2003. To contribute, send email to jsr–114–comments at jcp.org. The review and reference implementation are available at http://jcp.org/aboutJava/communityprocess/review/jsr114/index2.html.
The JAIN (Java Advanced Intelligent Network) API’s are a set of libraries that enable the rapid development of Next Generation telecom products and services on the Java platform. The JAIN APIs bring service portability, convergence, and secure network access to telephony and data networks. 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 public review of this specification ends on September 26th 2003. To contribute, send email to Jbakker at telcordia.com. The review and reference implementation are available at http://jcp.org/aboutJava/communityprocess/review/jsr122/index.html.
Community Draft Approvals
The Community Draft Specification is the specification developed in collaboration by members of the expert group for the JSR. The following community draft specifications were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)
This JSR will define a dense download format for Java classfiles. It is expected that this format can achieve considerable size savings over compressed JAR files. Currently the Java platform uses Java Archive (JAR) encapsulation of these applications and their classes. The Java archive format can compress these classes at the byte level only, leading to a meager reduction factor of about two. There is a need to compress the classes much more efficiently, thus making network transfers faster and therefore more reliable. As a starting point, the Sun developed PACK format, which has been successfully tested to achieve reduction factors of 7–9 will be used.
Metadata are annotations that mark particular fields, methods, and classes as having attributes that should be processed in special ways by development tools, deployment tools, or run–time libraries.
For example, the JavaBeans architecture introduced various stylistic naming patterns (such as getFoo/setFoo method names) that could be used to indicate that particular methods were used for accessing properties, for registering event handlers, and so forth. Similarly the Enterprise JavaBeans architecture introduced various stylistic patterns that allow methods to be marked as remote methods, home methods, and the like. The EJB architecture defines significant extra information in its deployment descriptors that is used to provide information on things like the persistence relationships of fields, the transactional properties of methods, and so forth. Source code defining web services components has similar needs.
Custom tools may use metdata to generate auxillary source files to be used in conjunction with the source file containing the annotation. For example, a stub generator could generate remote procedure call stubs based on annotations indicating that certain methods are designed for remote use.
This JSR intends to add to the Java programming language a means of associating arbitrary attribute information with particular classes/interfaces/methods/fields. This mechanism is referred to as the Java programming language metadata facility. This facility is meant to replace the various ad hoc metadata facilities in use today.
This JSR will
- Define a Java programming language feature that allows medatadata information to be supplied for (at least) classes, interfaces, methods, and fields. This language extension will allow metadata to be recognized by development tools by using using a doc comment tag @meta or adding a new Java programming language keyword meta or any other mechanism deemed suitable by the expert group.
- Define a runtime delivery format for metadata and of runtime APIs so that tools and libraries can accesss metadata information at deployment time and at runtime.
- Define rules for the attribute namespace so as to avoid accidental collisions over the same attribute name.
For a detailed explanation of the features this JSR implements, please refer my previous article describing the features of the Java 1.5 platform release (http://www.developer.com/java/other/article.php/2213791)
This JSR will modify and extend the Java Class File format to support updates to the Java platform and language specifications. The JSR will add support for quicker and more efficient byte code verification, class literal support directly from the class file format and will increase certain implicit size limits within the class file.
JSR–201 Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
This JSR proposes four new JavaTM programming language features: enumerations, autoboxing, enhanced for loops and static import.
For a detailed explanation of the features this JSR implements, please refer my previous article describing the features of the Java 1.5 platform release (http://www.developer.com/java/other/article.php/2213791).
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 Specification Lead, Aaron Williams of Sun Microsystems sent out a call to all those involved in the JCP process. Since this is a community effort, I would like to reproduce the contents of the email sent he sent out and encourage readers of this column to participate
“This update (to the JCP) is designed to encourage JSRs to be more transparent to the community and public, and to make it easier for people to get more meaningfully involved in the work of the community.
JSR 215 entered Community Review last Friday, and 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 here: 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!
This JSR is an update to JAXP 1.2 (JSR-63 Java API for XML Processing 1.2) to support the current evolving XML processing standards. The revised XML standards incorporate changes based on several years of growing implementation experience. In particular this update will address the following revisions of core XML standards such as DOM Level 3 Specifications, XML 1.1 and related Namespaces specifications and SAX 2.0.1. This update will also focus on improving performance of XML processing, allowing better client control over the characteristics of the XML processor, XInclude support and support for future revisions to XPath and XSLT.
The Java Language and VM specifications specify the semantics of threads and locks, as well as related features such as volatile variables. Unfortunately, the current specification has been found to be hard to understand and has subtle, often unintended, implications. Certain synchronization idioms sometimes recommended in books and articles are invalid according to the existing specification. Subtle, unintended implications of the existing specification prohibit common compiler optimizations done by many existing Java virtual machine implementations. Enforcing these aspects of the specification would be prohibitively expensive on many existing processor architectures. It is doubtful that enforcement of these implications would be useful to programmers, regardless of the cost of enforcing them. Several important issues, such as the interaction between synchronization and final fields, simply aren’t discussed in the existing specification. The proposed specification describes the semantics of threads, locks, volatile variables and data races. The specification is expected to revise substantially Chapter 17 of “The Java Language Specification” and Chapter 8 of “The Java Virtual Machine Specification”. It is not expected to result in changes to existing APIs, but might clarify the semantics of some existing methods in java.lang.Thread and java.lang.Object (java.lang.Object defines the wait and join methods). This will enable Java programmers to write reliable multithreaded software and understand which thread communication idioms are legal. It will also allow Java virtual machine (JVM) implementors to implement specification compliant and high-performance JVMs.
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
Proposed Final Draft 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 specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr180/index.html. To contribute, send email to jsr-180-comments at jcp.org.
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.
The specification and reference implementation are available at http://jcp.org/aboutJava/communityprocess/first/jsr168/index2.html. To contribute, send email to jsr-168-comments at jcp.org.
The goal of this specification is to develop APIs and conventions that support processing XML as a stream of XML (as opposed to using a document metaphor for processing). The specification will address three main areas:
- Develop APIs and conventions that allow a user to programmatically pull parse events from an XML input stream. Pull parsing is a programming technique in which the developer calls methods requesting the next event during parsing rather than receiving an automatic callback from the parser (like in SAX processing)
- Develop APIs that allow a user to write parse events to an XML output stream.
- Develop a set of objects and interfaces that encapsulate and implement programmer friendly access to information contained in an XML stream.The streaming API gives parsing control to the programmer by exposing a simple iterator based API. This allows the programmer to ask for the next event (pull the event) and allows parsing state to be stored in a procedural fashion.
The specification and reference implementation are available at http://jcp.org/aboutJava/communityprocess/first/jsr173/index.html. To contribute, send email to jsr-173-comments at jcp.org.
The Java community needs a standard way to create, store, access and maintain data and metadata in OLAP systems serving J2EE–compliant application servers. Currently, there is no widely-agreed upon, standard API for doing this. By using JOLAP, implementors of OLAP systems can expose a single, standard API that will be understood by a wide variety of client applications and components running on the J2EE Platform. Similarly, OLAP clients can be coded against a single API that is independent of the underlying data resource (e.g., native multidimensional database versus relational star-schema). The ultimate goal of JOLAP is to provide for OLAP systems what JDBC did for relational databases. The JOLAP specification will address the need for a pure Java API that supports the creation, storage, access and maintenance of data and metadata in OLAP servers and multidimensional databases.
The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr69/index.html. To contribute, send email to jsr–69–comments at jcp.org.
JSR Final Release
At this stage the final specification, Technology Compatibility Kit (TCK) and reference implementations are available for developers to use.
This specification will define a generic interface for positioning. As such, this API shall work with most positioning methods, such as GPS or E–OTD, but the core API will not expose features that pertain to one technology only (however it may allow extensions for specific purposes).
You may download the final specification from http://jcp.org/aboutJava/communityprocess/final/jsr179/index.html.
- Java 2 Mobile Edition Implementation and Information: http://java.sun.com/products/j2meJ2ME Connected Device Configuration Implementation and Information: http://java.sun.com/products/cdc
- Connected, Limited Device Configuration (CLDC): http://java.sun.com/products/cldc/
- Mobile Information Device Profile (MIDP): http://java.sun.com/products/midp
- 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
- Connected, Limited Device Configuration (CLDC): http://java.sun.com/products/cldc/
- Mobile Information Device Profile (MIDP): http://java.sun.com/products/midp
- World Wide Web Consortium, where you will find all the XML specifications: http://w3c.org
- SyncML.org and Open Mobile Alliance Specifications for Data Synchronization: http://www.syncml.org
- JDBC Specification: http://java.sun.com/jdbc/download.html
- JDBC Rowset tutorial: http://developer.java.sun.com/developer/Books/JDBCTutorial/chapter5.html
- JSR-63 JavaTM API for XML Processing 1.2: http://jcp.org/en/jsr/detail?id=63
- Simple API for XML (SAX): http://www.saxproject.org/
- Common Warehouse Metamodel (CWM) Specifications: http://cgi.omg.org/techprocess/faxvotes/CWMI_RFP.html
- OLAP Council Multidimensional API: http://www.olapcouncil.org/research/apily.htm
- OMG MOF, UML and XMI Specifications: http://cgi.omg.org/techprocess/meetings/schedule/tech2a.html#mod
- All about Session Initiation Protocol (SIP): http://www.sipcenter.com/aboutsip/whatissip.html
- 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/
- An Introduction to the Java 1.5 (Tiger) release: http://www.developer.com/java/other/article.php/2213791
- The Java Memory Model web page: http://www.cs.umd.edu/~pugh/java/memoryModel
- Fixing the Java memory model, Proceedings of the ACM 1999 conference on Java Grande, 1999 http://www.acm.org/pubs/citations/proceedings/plan/304065/p89-pugh/ Slides at: http://www.cs.umd.edu/~pugh/java/jmmSlides.pdf
- The Java Memory Model, Section 2.2.7 of Concurrent Programming in Java, 2nd edition, Doug Lea, Addison Wesley, 1999: http://gee.cs.oswego.edu/dl/cpj/jmm.html
- Concurrent Programming in Java, 2nd edition, Doug Lea: http://gee.cs.oswego.edu/dl/cpj/index.html
- Proposed revision to Section 17.4, Wait Sets and notification, Doug Lea: http://gee.cs.oswego.edu/dl/html/jvms.html
- Improving the Java Memory Model with CRF, Jan-Willem Maessen, Arvind and Xiaowei Shen, Computation Structures Group Memo 428, MIT, 2000: http://www.csg.lcs.mit.edu/~earwig/java-mem.ps
- Multithreaded semantics for Java, by Jeremy Manson and William Pugh, available as UMCP CS Tech Report #4215: http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
- 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
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.