This past month, the Tiger (Java 5.0 platform) JSR and several dependent JSRs made it past the final approval ballot. Several early access specifications were made public under the new JCP 2.6 guidelines. Further, the Java Wireless Messaging API was published in its final form.

Approved JSRs

One JSR was approved for further development under the guidelines of the JCP. This JSR was approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)

JSR-247 Data Mining 2.0 (http://jcp.org/en/jsr/detail?id=247)

This JSR intends to extend the earlier version of the Java Data Mining API, JDM 1.0 JSR-73 (http://jcp.org/en/jsr/detail?id=73). JDM is an API that supports data mining operations and activities. The goal of JDM is to provide for data mining systems what JDBC did for relational databases. Java Data Mining 2.0 will address requested features deferred from JDM 1.0. JDM 2.0 extends JDM with requested functionality for new mining functions, mining algorithms, and corresponding web services specification. Features that should be considered in JDM 2.0 include, but are not limited to, the following:

Sequential Patterns / Time Series - mining functions to address forecasting and modeling seasonal or periodic fluctuations in data.

Transformations interface - data preparation is a key aspect of any data mining solution. A separate JSR for transformations is likely warranted. Having a close integration with such a JSR and addressing transformations in the next version has high priority.

Ensemble models - define composite models structured with logic, e.g., boosting and bagging approaches.

Apply for Association - augment specification to enable prediction based on association rules.

Text Mining - enable mining of unstructured text data both by explicit feature extraction and the accepting of text attributes as model predictors

Model Comparison - introduce ability to compare multiple models according to various quality metrics, e.g., accuracy and lift for classification.

Multi-record real-time scoring - enable scoring of multiple records in the record apply task as a performance optimization for applications.

Multi-target models - enable the specification of multiple targets for supervised models as a model performance and representation optimization.

Early Access Reviews

The preliminary draft of the specification is one that both the community and the public may review. Anyone with an Internet connection can read and comment on the draft. The expert group uses feedback from the review to revise and refine the draft. The following JSRs released early draft specifications

JSR-209 Advanced Graphics and User Interface Optional Package for the J2ME Platform (http://jcp.org/en/jsr/detail?id=209)

The primary goal for this JSR is to provide support for core graphics capabilities on the J2ME platform. It intends to migrate the core APIs for advanced graphics and user interface facilities from the J2SE platform to the J2ME platform. These facilities will include: Swing, Java 2D Graphics and Imaging, Image I/O, and Input Method Framework. This JSR does not intend to modify the existing API's thereby making applications written to this subset of the graphics libraries fully upward compatible to J2SE.

This JSR will be under review until 7th August 2004. To contribute, send an email to jsr209-review-comments@jcp.org. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=pbp_agui-1.0-edr-spec-jdoc-oth-JSpec&SiteId=JCP&TransactionId=noreg

JSR-220 Enterprise Java Beans 3.0 (EJB 3.0) (http://jcp.org/en/jsr/detail?id=222)

This JSR is an extension to the earlier EJB 2.1 specification (http://jcp.org/en/jsr/detail?id=153) aiming to improve the EJB architecture by reducing its complexity from the developer's point of view. The JSR expects that metadata attribute annotations will play a large role in this simplification. The scope of the JSR is not limited to simplification through the use of metadata, however. It will consider a variety of other features that can promote ease-of-use. Aspects that will be considered include:

Definition of the Java metadata attributes that can be used to annotate EJB applications. Such metadata will be also be targeted at reducing or eliminating the need for the bean developer to provide an EJB deployment descriptor. Use of metadata will further enable the generation of component and home interfaces for an EJB component from the enterprise bean class itself.

Specification of programmatic defaults, including for metadata, to reduce the need for the developer to specify common, expected behaviors and requirements on the EJB container.

Definition of utility classes to reduce the number of interfaces and/or callback methods that the bean developer must implement.

Encapsulation of environmental dependencies and JNDI access through more convenient utility classes and/or factory patterns.

Simplification of the stateless session bean type or the introduction of a simplified EJB component that more closely resembles a plain Java class.

Enhancements to container-managed persistence and EJB QL to provide greater usability and to facilitate the development of frameworks based on container-managed persistence.

Reduction of the requirements for usage of checked exceptions.

Enhancements to facilitate performance optimizations by EJB container vendors.

Requests for other enhancements to the EJB architecture to be considered by the Expert Group

This JSR will be under review until 30^th July 2004. To contribute, send an email to ejb3-feedback@sun.com. The specification is available for download at http://java.sun.com/products/ejb/docs.html

JSR-222 Java API for XML Data Binding (JAXB) 2.0 (http://jcp.org/en/jsr/detail?id=222)

JAXB 2.0 is a follow-on to JSR 31 Java XML Data Binding Specification building upon the architecture introduced in JAXB 1.0. JAXB 2.0 proposes additional functionality while retaining ease of development as a key goal. In particular, this JSR intends to:

Leverage JSR 14, JSR 201 and JSR 175 resulting in a better and simpler binding, thus making the application development easier. The use of the language extensions will be enabled using a compiler switch

Address the XML to Java object binding requirements for JAX-RPC (JSR-101) enabling a tighter coupling and a primary implementation of JAXB and JAX-RPC

Specify the mapping between Java objects to XML Schemas. This addresses scenarios where an application design begins with Java objects rather than an XML schema. One such example is an application that exports itself as a web service that communicates using SOAP and XML as a transport mechanism

Enable serialization of Java objects to XML schemas and vice-versa

Investigate the implementation of a portable, standalone runtime for JAXB, schema evolution, partial object to XML binding and the integration of JSR Streaming API for XML) into JAXB architecture.

This JSR will be under review until 23^rd July 2004. To contribute, send an email to spec-comments@jsr222.dev.java.net. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jaxb-2_0-edr-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg

JSR-223 Scripting Pages in Java Web Applications (http://jcp.org/en/jsr/detail?id=223)

There are a number of scripting languages that are being used today to generate dynamic content; notable examples include PHP, ECMAScript, Active Server Pages and others. Application developers using these technologies would like a standard mechanism to access information developed in the Java platform. This Specification will describe how to write portable Java classes that can be invoked from a page written in an scripting language, including details on security, resources and class loader contexts. The specification will cover both the case where the Java classes are instantiated in a Java Servlet container and the case of a Java VM. The specification may include a Java API that can be used, possibly through JNI, by a scripting language engine to access the desired Java objects. The specification will also describe how to package these scripting pages and Java classes, including how to bundle the scripting pages into a WAR file.

The way Java objects are represented and accessed in a given scripting language is specific to that scripting language but we expect this specification to indicate some common requirements for these mappings. The specification will be grounded in some specific mappings, which may or not be included as part of the specification. The reference implementation will include support for interoperability with the PHP scripting language.

This JSR will be under review until 1th August 2004. To contribute, send an email to jsr-223-comments@jcp.org. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=java_scripting-1_0-edr-spec-oth-JSPEC&SiteId=JCP&TransactionId=noreg

JSR-224 Java API for XML-Based RPC (JAX-RPC) 2.0 (http://jcp.org/en/jsr/detail?id=224)

The JAX-Remote Procedure Call 2.0 specification extends the existing JAX-RPC 1.0 (JSR 101) specification with new features, including some or all of the following: direct support for JAXB 2.0-based data binding, support for the latest W3C and WS-I standards (e.g. SOAP 1.2, WSDL 1.2), standardized metadata for Java<->WSDL mapping, ease-of-development features, support for easier evolution of Web services, an improved handler framework, support for asynchronous RPC and non-HTTP transports.

This JSR will be under review until 23^rd July 2004. To contribute, send an email to jsr-223-comments@jcp.org. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jaxrpc-2.0-edr-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg

JSR-238 Mobile Internationalization API (http://jcp.org/en/jsr/detail?id=238)

This specification will provide a common API for the internationalization of MIDP applications, delivered and licensed as an optional package. It intends to provide the means to isolate localizable application resources from program source code and an API for accessing those resources at runtime, selecting the correct resources for the user's/device's locale. The specification will also define an API for supporting cultural conventions in applications such as formatting dates, times, numbers, and currencies, and sorting text strings correctly for the user's locale.

This JSR will be under review until 23^rd July 2004. To contribute, send an email to jsr-238-comments@jcp.org. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2me_i18n-0.4-edr-oth-JSpec&SiteId=JCP&TransactionId=noreg

JSR-243 Java Data Objects 2.0 - An Extension to the JDO specification (http://jcp.org/en/jsr/detail?id=243)

The JDO API provides a database abstraction that permitted API access to datastores without detailed knowledge of the underlying datastore API. This specification builds on the original, adding the following features

Relational Database Mapping: Different JDO implementations have slightly different mappings to relational databases and the mappings are not portable among vendors. This JSR will address a common mapping format to allow a higher degree of portability of applications.

Disconnected operation: A primary use-case for JDO is in a middle tier of a multi-tier architecture. Rich clients (http clients running applets, web services clients, and ORB clients) may wish to extract a subset of values from the database in a structured (domain model) format, and update this information. Once updated, the information is sent back to a middle tier, where the changes are applied to the datastore. This JSR will address the APIs in the middle tier to facilitate this use-case.

Broaden the range of implementations: Certain JDO 1.0 specification restrictions reduce the acceptance of the API by potential JDO vendors. Limitations include a requirement for binary compatibility to the Reference Enhancement contract and a requirement that only classes, not interfaces, can be persistent. This JSR will address these limitations.

Alignment with J2EE: While the JDO technology is suitable as a component in the J2EE architecture, certain services are required from the server that is not currently standardized. Part of this JSR will recommend standard APIs to provide these services. Part of this alignment will specify the portable behavior of transaction completion in the web and EJB containers.

Extensions to JDO queries: JDOQL provides a standard way to access persistent instances based on values and relationships, but is limited in what can be returned as the result. This JSR will extend the range of return values to include projected fields, collections of instances identified in navigational expressions, and aggregate data such as MIN, MAX, SUM, AVG, and COUNT. Additional methods will be defined to perform string manipulations in filters.

Relationships: The JDO object model does not specify bidirectional or composition relationships among object classes. This JSR will consider issues regarding managed bidirectional relationships and composition relationships including cascade delete semantics.

Maximize JDO backward compatibility: Many applications and deployments have significant investments in the JDO technology. Any improvements to the API will attempt to maintain backward compatibility to all previous JDO specifications.

This JSR will be under review until 7^th August 2004. To contribute, send an email to jsr-243-comments@jcp.org. The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jdo-20-edr-oth-JSpec&SiteId=JCP&TransactionId=noreg

JSR 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)

JSR-113 Java Speech API 2.0 (http://jcp.org/en/jsr/detail?id=113)

This JSR extends the work of the 1.0 Java Speech API which allows developers to incorporate speech technology into user interfaces for their Java programming language applets and applications. This API specifies a cross-platform interface to support command and control recognizers, dictation systems, and speech synthesizers. Version 2.0 will extend Sun's s pre-JCP work on JSAPI 1.0. JSAPI does not provide any speech functionality itself, but through a set of APIs and event interfaces, access to speech functionality provided by supporting speech vendors is accessible to the application.

While JSAPI 1.0 is a great start, there are still some issues to be resolved. Candidate targets for JSAPI 2.0 include:

A service provider interface (SPI) will act as middleware between the JSAPI Layer and the vendor-provided speech engine. This may be based on existing standards such as the SAPI 5.0 service provider API.

The JSGF and JSML specs must track the W3C Voice Browser group's grammar format and synthesis markup languages.

Built in support for redirection of audio.

Various threading issues (e.g., synchronization via event queues) and reentrancy issues require tighter specification.

A modular architecture that supports a very small minimum configuration and future growth for the resources of a variety of platforms (e.g., desktop, server).

Various other specification details require clarification.

Future consideration for compatibility with telephony APIs (e.g., JTAPI or JAIN).

Proposed Final Draft Specifications

JSR 133: Java Memory Model and Thread Specification Revision (http://jcp.org/en/jsr/detail?id=133)

This specification intends to revise Chapter 17 of "The Java Language Specification" and Chapter 8 of "The Java Virtual Machine Specification" by clarifying and further specifying the semantics of threads, locks, volatile variables and data races. 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. Several important issues, such as the interaction between synchronization and final fields, simply aren't discussed in the existing 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 such as wait() and join(). It also expects to clarify programming constructs and concepts such as volatile and final variables, immutable objects and thread- and memory-related JVM functionality and APIs such as class initialization, asynchronous exceptions, finalizers, thread interrupts, and the sleep, wait, and join methods of class java.lang.Thread

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=memory_model-1.0-pfd2-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg . To contribute, send email to jsr-133-comments@jcp.org

JSR 176: J2SE 1.5 (Tiger) Release Contents (http://jcp.org/en/jsr/detail?id=234)

This JSR is to develop a specification for the feature and API set for the next feature release of Java 2 Standard Edition, code named "Tiger", targeted to ship Q3 CY 2004. Tiger is one of a series of feature releases to J2SE. The intention is to ship feature releases on a regular 18-month cycle, with each release including a combination of quality improvements and a small amount of new features.

Various existing JSR API initiatives will be evaluated as potential candidates for Tiger. Amongst the possible candidates for evaluation are:

JSR-003 Java Management Extensions (JMX) Specification (http://jcp.org/en/jsr/detail?id=3)

JSR-013 Decimal Arithmetic Enhancement (http://jcp.org/en/jsr/detail?id=13)

JSR-014 Add Generic Types to the Java Programming Language (http://jcp.org/en/jsr/detail?id=14)

JSR-028 Java SASL Specification (http://jcp.org/en/jsr/detail?id=28)

JSR-114 JDBC Rowset Implementations (http://jcp.org/en/jsr/detail?id=114)

JSR-133 Java Memory Model and Thread Specification Revision (http://jcp.org/en/jsr/detail?id=133)

JSR-163 Java Platform Profiling Architecture (http://jcp.org/en/jsr/detail?id=163)

JSR-166 Concurrency Utilities (http://jcp.org/en/jsr/detail?id=166)

JSR-174 Monitoring and Management Specification for the Java Virtual Machine (http://jcp.org/en/jsr/detail?id=174)

JSR-175 A Metadata Facility for the Java Programming Language (http://jcp.org/en/jsr/detail?id=175)

JSR-199 Java Compiler API (http://jcp.org/en/jsr/detail?id=199)

JSR-200 Network Transfer Format for Java Archives (http://jcp.org/en/jsr/detail?id=200)

JSR-201 Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import (http://jcp.org/en/jsr/detail?id=201)

JSR-204 Unicode Supplementary Character Support (http://jcp.org/en/jsr/detail?id=204)

JSR-206 Java API for XML Processing (JAXP) 1.3 (http://jcp.org/en/jsr/detail?id=206)

The final specification for Tiger may not include all of these JSRs, and may include some JSRs not present on this list.

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2se-1.5.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg. To contribute, send an e-mail to jsr-176-comments at jcp.org

JSR-200 Network Transfer Format for Java Archives (http://jcp.org/en/jsr/detail?id=200)

This JSR will define a dense download format for Java class files. 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.

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=network_transfer_format-1.0-pfd2-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg. To contribute, send an e-mail to jsr-200-comments at jcp.org

JSR-212 Server API for Mobile Services: Messaging - SAMS: Messaging (http://jcp.org/en/jsr/detail?id=212)

Mobile network services such as short message service (SMS) and multimedia message service (MMS) have gained tremendous popularity among users of mobile phones. Increasingly it is becoming necessary to provide J2EE and J2SE a standard, universal mechanism of compose, send and receive SMS and MMS messages as application developers add support for these technologies in their application servers or backend systems. The goal of this JSR is to provide API's for Java applications on top of J2SE/J2EE to compose, send and receive short messages and multimedia messages.

According to the proposal, the scope of this API will not limit itself to only SMS and MMS but rather provide a high level API to accessing messaging mobile services, thereby accounting for future mobile messaging applications. It intends to serve as an example for future Java API's accessing mobile network services.

There are currently JSR's relating to support of SMS and MMS messaging on the mobile platform (J2ME), namely JSR 120 Wireless Messaging API: http://www.jcp.org/en/jsr/detail?id=120 JSR 205 Wireless Messaging API 2.0: http://www.jcp.org/en/jsr/detail?id=205 . The programming model for this JSR intends to be different from the above proposals. However it would be nice if there would a single standard interface to mobile network messaging across J2ME and J2SE/EE, rather than 2 distinct ones, at least API wise.

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=sams_messaging-1.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg. To contribute, send an e-mail to jsr-212-comments at jcp.org

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.

JSR 73: Data Mining API (http://jcp.org/en/jsr/detail?id=73)

The Java community needs a standard way to create, store, access and maintain data and metadata supporting data mining models, data scoring, and data mining results serving J2EE-compliant application servers. Currently, there is no widely agreed upon, standard API for data mining. The JDMAPI specification will address the need for a pure Java API that supports the building of data mining models, the scoring of data using models, as well as the creation, storage, access and maintenance of data and metadata supporting data mining results, and select data transformations.

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=dmapi-0.96-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.

JSR.69 Java OLAP Interface (JOLAP) (http://jcp.org/en/jsr/detail?id=69)

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, implementers 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://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7696-jolap-1.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.

JSR-177 Security and Trust Services API for J2ME (http://jcp.org/en/jsr/detail?id=177)

The intent of this JSR is to define a collection of APIs that provide security services to J2ME enabled devices. It will provide security mechanisms to support a wide variety of application-based services, such as access to corporate network, mobile commerce, and digital rights management. These services rely on the existence of a "Security Element" in the device for storage and execution of sensitive data and operations. This Security Element will provide secure storage to protect sensitive data, secure execution (such as cryptographic operations to support payment protocols, data integrity, and data confidentiality) and the ability to customize and enable secure features provided by the device. The most commonly implemented Security Element currently is a Smart card, which is widely deployed in wireless phones. This specification provides an access model that enables applications running on J2ME enabled devices to communicate with a smart card inserted in the device. This access model intends to provide a flexible mechanism to allow service and equipment providers to define secure operations.

The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2me_satsa-1.0-pfd-oth-JSpec&SiteId=JCP&TransactionId=noreg.

JSR Final Release

At this stage the final specification, Technology Compatibility Kit (TCK) and reference implementations are available for developers to use.

JSR-205 Wireless Messaging API (http://jcp.org/en/jsr/detail?id=205)

The original JSR (JSR-120) dealing with wireless messaging was confined to Short Message Service (SMS), Unstructured Supplementary Service Data (USSD) and Cell Broadcast Service (CBS). All of these messaging technologies deal with text based messaging. SMS allows sending of text messages to another cell phone. USSD is similar to SMS but unlike SMS messages, which get saved if the cell phone is unavailable USSD messages are generated and consumed within a single session, while the cell phone is active. Finally CBS allows for broadcasting text messages to a set of cell phones within a geographical area.

Text based messaging is widely prevalent today primarily due to the nature of deployed wireless networks. These mobile networks are referred to as 2G (2nd Generation) networks and allow transmission of data at speeds up to 14.4Kbs. Now as mobile network technologies have matured the deployment of 3G (3rd Generation) networks has started taking place. 3G networks allow transmission of data at speed up to 2Mbps which makes these networks capable of transmitting not only text but also video and audio to wireless devices. 3G capable mobile handsets have also become widely available.

Java already has support for text based messaging using SMS, USSD and CBS. This JSR intends to extend the existing wireless messaging API's 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 final specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=wma_ext-102-fr-oth-JSpec&SiteId=JCP&TransactionId=noreg

Rejected JSR

The JCP Expert group for J2ME (http://jcp.org/en/participation/committee#ME) rejected the following specification related to interfacing with a mobile device's native management system. The reason for rejection was primarily inconsistent information as part of the specification request and potential overlap with existing JSRs.

JSR 246 Device Management API (http://jcp.org/en/jsr/detail?id=246)

The purpose of this JSR is to enable J2ME applications to access device management implementations.

What do you think of the JCP? What do you think of the current JSRs? Do you have any suggestions for this column? Feel free to write to me at jcpwatch at jcpwatch.org

JCP Watch: Getting closer to Tiger