JCP Watch: Getting closer to Tiger
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.
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:
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 firstname.lastname@example.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:
This JSR will be under review until 30th July 2004. To contribute, send an email to email@example.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:
This JSR will be under review until 23rd July 2004. To contribute, send an email to firstname.lastname@example.org. 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 email@example.com. 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 23rd July 2004. To contribute, send an email to firstname.lastname@example.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 23rd July 2004. To contribute, send an email to email@example.com. 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
This JSR will be under review until 7th August 2004. To contribute, send an email to firstname.lastname@example.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:
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 email@example.com
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:
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
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