Two JDBC related JSRs went final over the past few week. The first deals with an optional package for the J2ME mobile Java platform while the other introduces a long awaited Rowset specification for programmatic iteration over tabular data. Further, public review specifications for Java 1.5 (J2SE, Tiger) and an approval to start work on defining J2EE 1.5 were also released.
JSR-245 JavaServer Pages 2.1 (http://jcp.org/en/jsr/detail?id=245)
Java Server Pages are a set of API.s used to develop web pages that contain small pieces of Java code. When a web server receives a request for such a page, it calls a JSP engine to execute the Java code within the page. This execution results in dynamic and personalized content. Currently JSP 1.2 is the accepted and most recent standard. This JSR specifies the next revision to the JSP specifications. Significant changes relate to ease of use and development of JSP pages for non-technical resources (like web page designers), The purpose of JSP 2.1 is to improve alignment with JavaServerFaces (JSF) and enhance ease of development.
This JSR will be under public review until 24th May 2004. To contribute, send an email to jsr-245-comments at jcp.org
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 242: Digital Set Top Box Profile - "On Ramp to OCAP" (http://jcp.org/en/jsr/detail?id=242)
The existing Java platforms are generally too large in implementation size and too demanding in functionality to be used with the majority of already-deployed cable television set top boxes in the United States and elsewhere. There is a pressing market need to identify a Java platform that can be used with less-capable digital cable set top boxes that are currently deployed and will remain in the field for some time. The proposed specification will define a common API for applications that can be used by all vendors targeting the already-deployed digital cable set top box market. It will also provide a clear path of upward compatibility for content to migrate from the target low-end platform to OCAP (OpenCable Applications Platform, http://www.opencable.com), the Java middleware platform of next-generation North American cable set top boxes. OCAP is related to DVB-MHP (Multimedia Home Platform, http://www.mhp.org), the Java middleware of choice for next generation interactive television (iTV) devices in Europe and elsewhere.
The goal of this specification is to create a platform that is as forward compatible as possible with OCAP while still fitting on the most resource constrained of the currently deployed cable television set top boxes that are capable of running J2ME CLDC.
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 are 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.
JSR 244: Java 2 Platform, Enterprise Edition 1.5 (J2EE 1.5) Specification (http://jcp.org/en/jsr/detail?id=244)
This JSR is to develop J2EE 1.5, the next release of the JavaTM 2 Platform, Enterprise Edition, targeted to ship in the second half of 2005.
The major theme for the next version of J2EE is ease of development. JSR-175 (A Metadata Facility for the Java Programming Language) is the enabling facility for a new declarative style of programming that significantly simplifies many programming tasks. J2EE must move quickly to take advantage of this capability and deliver significant improvements to ease of development for J2EE developers.
The JSR proposes that:
This JSR will not itself define any new APIs, rather it will enumerate APIs defined in other JSRs which include:
Public Review Specifications
The following JSRs were released for public review.
JSR-161 JAIN ENUM API Specification (http://jcp.org/en/jsr/detail?id=161)
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. ENUM is a Domain Name System (DNS) based protocol defined by the IETF in [RFC2916]. General DNS resolver APIs and implementations expose the low-level protocol of DNS and do not encapsulate the specialized processing required by ENUM. The JAIN ENUM API hides the complexities of DNS resolution and Dynamic DNS provisioning (DDNS) [RFC2163], while encapsulating the higher-level services of ENUM, including POSIX Regular Expression Handling, Resolution Service and Protocol Filtering, Security (DNSSEC) [RFC2535], Extended DNS Support (EDNS0) [RFC2671, etc. The JAIN ENUM API specification enables applications to query and provision ENUM entries (i.e. E.164 telephone numbers and their service-specific URIs) into an ENUM registry.
The public review of this specification ends on June 10th 2004. To contribute, send email to jsr-161-comments at jcp.org. The review is available at http://jcp.org/aboutJava/communityprocess/review/jsr161/index.html
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.
This is the second update to the final draft. This JSR will be under public review until 10th June 2004. To contribute, send an email to jsr-176-comments at jcp.org. The review is available at http://jcp.org/aboutJava/communityprocess/review/jsr176/index2.html
JSR-234 Advanced Multimedia Supplements (http://jcp.org/en/jsr/detail?id=234)
Java equipped terminals are evolving into general multimedia and entertainment platforms. Features like camera and radio which have traditionally belonged into different device categories are now integrated into same terminals. Increase in the processing power of modern mobile phones allow more sophisticated media processing capabilities. Displays will remain relatively small due physical limitations but rich aural experience can be achieved without adding the physical size of the terminals. The purpose of this API is to give access to multimedia functionality of the modern mobile terminals. Specifically, better support for camera and radio and access to advanced audio processing will be introduced but it.s possible to add other functionality as well.
MMAPI (JSR-135) is the media package for J2ME/CLDC environment which introduces basic playback functionality for audio and video. It allows media players to be created for various sources including camera and radio but it does not offer any specific methods to control them.
This specification will bring the following capabilities to the mobile terminals with J2ME/CLDC support:
This JSR will be under public review until 24th May 2004. To contribute, send an email to jsr-234-comments at jcp.org. The review is available at http://jcp.org/aboutJava/communityprocess/edr/jsr234/index.html
JSR 181: Web Services Metadata for the Java Platform (http://jcp.org/en/jsr/detail?id=181)
Java Language Metadata (JSR 175 http://jcp.org/en/jsr/detail?id=175) is a recently submitted JSR that provides a standard model for annotating Java code, of which Web Services Metadata for the Java Platform will be one application that provides an easy to use syntax for describing web services at the source-code level for the J2EE platform. The specification is intended to provide a syntax that is amenable to manipulation by tools. In principle this JSR will provide a decorator development pattern similar to what JSP.s are to Servlets. Developers would now be able to specify web services using metadata. This metadata will get processed by Web Service containers, J2EE app servers etc. to produce fully functional, provisionable, deployable and interoperable web service implementations.
This JSR will be under public review until 10th June 2004. To contribute, send an email to jsr-181-comments at jcp.org. The review is available at http://jcp.org/aboutJava/communityprocess/edr/jsr181/index.html
JSR-212 Server API for Mobile Services: Messaging - SAMS: Messaging (http://jcp.org/en/jsr/detail?id=181)
This JSR proposing to add API's for Java applications on top of J2SE/J2EE to compose, send and receive short messages and multimedia messages has been approved. This JSR has been covered in a previous installment available at http://www.developer.com/java/other/article.php/2196541
This JSR has been approved in it.s final review ballot. To contribute, send an email to jsr-181-comments at jcp.org. The review is available at
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-211 Content Handler API (http://jcp.org/en/jsr/detail?id=211)
The purpose of this JSR is to define an optional package for an API and associated model permitting the invocation of J2ME Applications to handle actions on Uniform Resource Identifiers (URI) based on the MIME-type or scheme. For example, an application or suite of applications running on the J2ME platform can register itself to be invoked when a particular content type in encountered. This is similar to file associations within web browsers that invoke particular programs when certain types of data are encountered (.PDF files invoke Adobe Acrobat).
Proposed Final Draft Specifications
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://jcp.org/aboutJava/communityprocess/first/jsr073/index.html. To contribute, send email to jsr-73-comments at jcp.org
JSR-105 XML Digital Signature APIs (http://jcp.org/en/jsr/detail?id=105)
This JSR is to define a standard set of APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, the XML Digital Signature specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. The XML Digital Signature specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.
The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr105/index.html. To contribute, send email to jsr-105-comments at jcp.org
JSR-163 Java Platform Profiling Architecture (http://jcp.org/en/jsr/detail?id=163)
Platform profiling is the ability to extract usage statistics of a running JVM. Metrics include memory usage, CPU usage, object references etc. There is an experimental interface - the Java Virtual Machine Profiling Interface (JVMPI) that suffers from a number of design flaws, scalability issues, sizeable overhead and imprecise profiling. The new profiling architecture intends to non-compatibly supercede JVMPI but provide similar yet enhanced functionality. These APIs will allow inter-operability of profiling and advanced garbage collection technologies. The APIs will allow reliable implementation on the widest range of virtual machines, part of which will be achieved by grouping functionality into optional sets. Queries for which optional capabilities are supported will be provided. The APIs will be targeted to provide a Java programming language model of execution, however, some aspects of the virtual machine, native and operating system models may be directly provided or provided via an extension mechanism. The APIs will accommodate implementations which can dynamically enable and disable profiling; and thus will allow implementations which have negligible performance impact when profiling is disabled. While profiling in the application development phase will be the primary goal of this specification, the design objectives for low performance overhead and data perturbation will also support profiling in the deployment phase.
The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr163/index.html. To contribute, send email to jsr-163-comments at jcp.org
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://jcp.org/aboutJava/communityprocess/first/jsr177/index.html. To contribute, send email to jsr-177-comments at jcp.org
JSR-226 Scalable 2D Vector Graphics API for J2ME (http://jcp.org/en/jsr/detail?id=226)
This specification will define an optional package API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format. The API is targeted for J2ME platform, with primary emphasis on MIDP. The main use cases for this API are map visualization, scalable icons, and other advanced graphics applications. The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for 2D graphics or floating point arithmetic. The API shall allow utilization of native 2D graphics features of the device when applicable. The API will have the ability to load and render external 2D vector images, stored in the W3C SVG Tiny format and the capability to render 2D images that are scalable to different display resolutions and aspect ratios.
The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr226/index.html. To contribute, send email to jsr-226-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-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.
You may download the final specification from http://jcp.org/aboutJava/communityprocess/first/jsr205/index.html
JSR-86 Enterprise Media Beans (http://jcp.org/en/jsr/detail?id=86)
EMB provides a framework to integrate rich media data such as audio, video or image into applications based on EJB Entity Beans within the J2EE application development model. It provides a common view on rich media from an application model point of view. EMB abstracts over underlying transport and rendering mechanisms (e.g. the various stream server implementations), caching and replication throughout the network. It ensures referential integrity and hides the underlying persistency method for rich media (file, binary large object, user defined data types, etc.) from the application model. EMB enforces a common security model for rich media, and ensure transactional behavior for operations like media insertion, remove or move. It standardizes the integration of en-de-transcoding mechanisms into the application model.
You may download the final specification from http://jcp.org/aboutJava/communityprocess/first/jsr086/index.html
JSR Final Release
At this stage the final specification, Technology Compatibility Kit (TCK) and reference implementations are available for developers to use.
JSR-114 JDBC Rowset Implementations (http://jcp.org/en/jsr/detail?id=114)
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 final specification is available at http://jcp.org/aboutJava/communityprocess/final/jsr114/index.html and the reference implementation is available at http://java.sun.com/products/jdbc/download.html#rowset1_0
JSR 169: JDBC Optional Package for CDC/Foundation Profile (http://jcp.org/en/jsr/detail?id=114)
The proposed specification will define a JDBC Optional Package for Java 2 Micro Edition (J2ME), Connected Device Configuration (CDC) Foundation Profile. This optional package will contain equivalent functionality to the java.sql package provided in Java 2 Standard Edition (J2SE). The functionality required should be adjusted to take into account the limitations of CDC in terms of size, functionality and removal of deprecated APIs. The JDBC Optional Package for CDC would provide a strict subset of the functionality available in J2SE.
The final specification is available at http://jcp.org/aboutJava/communityprocess/final/jsr169/index.html and the reference implementation is available at http://java.sun.com/products/jdbc/download.html
JDBC Specification: http://java.sun.com/jdbc/download.html
JDBC Rowset tutorial: http://developer.java.sun.com/developer/Books/JDBCTutorial/chapter5.html
An Introduction to the Java 1.5 (Tiger) release: http://www.developer.com/java/other/article.php/2213791
JSR-175 A Metadata Facility for the Java: http://jcp.org/en/jsr/detail?id=175
Java Server Faces homepage and reference implementation: http://java.sun.com/j2ee/javaserverfaces/
Java Servlet Technology: http://java.sun.com/products/servlet/index.html
Connected, Limited Device Configuration (CLDC): http://java.sun.com/products/cldc/
Starting point for all things related to the Java 2 Enterprise Edition Platform: http://java.sun.com/products/j2ee
The Wireless Messaging API implementation (JSR-120): http://java.sun.com/products/wma/
Wireless Messaging API 2.0: http://www.jcp.org/en/jsr/detail?id=205
SVG specification: http://www.w3.org/TR/SVG11/
Mobile SVG Profiles: http://www.w3.org/TR/SVGMobile/
The Java Advanced Intelligent Network (JAIN) API.s: http://java.sun.com/products/jain/index.html
Java TV API: http://java.sun.com/products/javatv
OpenCable Application Platform 1.0: http://www.opencable.com/specifications
OnRamp to OCAP 0.7.2 http://www.onramptoocap.com, http://220.127.116.11/~onrampto/OnRampJavadoc040406.zip, http://www.onramptoocap.com/OnRampJavadoc040406.zip
JSR-12 Java Data Objects (JDO) http://jcp.org/en/jsr/detail?id=12
JSR-14 Java Generics will be used as an alternative to certain JDO metadata http://jcp.org/en/jsr/detail?id=14
JSR-175 Metadata Facility will be used as an alternative to certain JDO metadata http://jcp.org/en/jsr/detail?id=175
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 apu at jcpwatch.org