http://www.developer.com/java/other/article.php/2229541/JCP-Watch-Scripting-language-support-in-Java-XQuery-API-Scalable-2D-graphics-for-J2ME.htm

Back to article

JCP Watch: Scripting language support in Java, XQuery API, Scalable 2D graphics for J2ME


June 30, 2003

In honor of JavaOne several new JSR's were submitted dealing with new versions of JDBC, XML Binding and XML-RPC. An important specification dealing with adding scripting language support to Java also was proposed during JavaOne. Further, the executive committee for J2ME overturned the earlier rejection ballot for updating the J2ME core specifications with Java 1.4 support.

New JSR's

Two new JSR's were submitted for approval to the JCP. The first deals with a new API adding support for the emerging W3C specification for querying XML documents (XQuery 1.0) while the other deals with adding scalable 2D vector graphics to J2ME.

JSR-225 XQuery API for Java (XQJ)

XQuery 1.0 is a query language being developed by the W3C XML Query Language Work Group, which defines a syntax for querying XML documents. XQuery is designed to be flexible enough to query a broad spectrum of XML information sources, including both databases and documents. This specification will define a set of interfaces and classes that enable an application to submit XQuery compliant queries to an XML data source and process the results of these queries.

This JSR will be under public review until 23rd June 2003. To contribute, send an email to jsr-225-comments@jcp.org.

JSR-226 Scalable 2D Vector Graphics API for J2ME

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.

This JSR will be under public review until 30th June 2003. To contribute, send an email to jsr-226-comments@jcp.org.

Approved JSR's

The Executive Committee for J2ME approved the reconsideration ballot cast for adding Java 1.4 support to core J2ME specifications. These JSR's will now continue further development under the guidelines of the JCP. The JSR's that were reconsidered and approved include:

The reconsideration ballot was cast in response to the modification of the JSR to decrease the requirement of ROM required to implement these specifications on supporting devices. Some members expressed their concern at the licensing terms and expressed concern about the need for such sweeping changes to the core J2ME API's.

You can find a more detailed description of these JSR's in my previous installment at http://www.developer.com/java/other/article.php/2203411.

JSR-220 Enterprise Java Beans 3.0 (EJB 3.0)

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
http://jcp.org/en/jsr/detail?id=14

JSR-221 JDBC 4.0 API Specification

The JDBC 4.0 API specification seeks to improve Java application access to SQL data stores by the provision of ease-of-development focused features and improvements at both the utility and API level. Using new Java language features planned for JSR-176 Java 2 Standard Edition 1.5 (http://jcp.org/en/jsr/detail?id=176), features such as annotations as defined in JSR-175 (http://jcp.org/en/jsr/detail?id=175), generics defined in JSR-014 (http://jcp.org/en/jsr/detail?id=14) in to addition to supplying a set of JDBC utility classes, SQL savvy developers will be able to more easily access SQL data sources while still benefiting from the full power of the JDBC API. In particular this JSR will specify mechanisms to assist developers in the following categories:

  • Management of JDBC Drivers: JDBC 4.0 seeks to provide utility classes to improve the JDBC driver registration and unload mechanisms.
  • Connection Management: Instead of constructing database specific JDBC URL's, JDBC 4.0 will specify a mechanism to allow applications to easily get a connection to any data source by simply supplying a set of parameters (host, port etc.) to a standard connection factory mechanism.
  • Statement and Result Processing: JDBC 4.0 will leverage the available J2SE 1.5 language improvements to allow the developer to more closely associate a SQL query with specific data representations such as class representations. It is anticipated that the Meta Data facility (JSR-175) in addition to Generics (JSR-014) facilities will allow a tight association of SQL queries with designated object structures describing query parameters.
  • Persistence and Update mechanisms will be standardized to allow a clearer definition between JDBC and complimentary persistence infrastructures.
  • Close Association with JDBC RowSet (part of Tiger, Java 1.5) implementations that enables disconnected data source access in addition to the ability to manage relational data stores from an XML stand-point.
  • Tighter coupling and reduced impedance between SQL query results and Java Objects through the use of utility classes.

JSR-222 Java API for XML Data Binding (JAXB) 2.0

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 developement 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.

JSR-223 Scripting Pages in Java Web Applications

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 clases 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 an 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.

JSR-224 Java API for XML-Based RPC (JAX-RPC) 2.0

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.

Public Review Specifications

JSR-127 JavaServer Faces

Typically web applications created in Java use Java Server Pages or Java Servlet technology. These programming models allow for the creation of complex server side processing logic but completely ignore client side interface to the application beyond custom HTML that is output from the server side execution. The goal of this specification is to provide server side support for modeling and interacting with user interface components implemented as Java Standard Tags for JSP and class libraries for servlets. It will create a standard way to define and reuse complex HTML forms and other common GUI elements by providing familiar APIs for GUI components, component state, rendering and input processing. To oversimplify, this JSR will provide standard tags and objects for HTML elements and define the associated event mechanisms, state management, validation support and other GUI component lifecycle support.

This is the second public review specification. The Public review closes on 4th July 2003. You may access the public review and early access release at http://jcp.org/aboutJava/communityprocess/review/jsr127/index2.html

JSR-173 Streaming API for XML

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:

  1. 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)
  2. Develop APIs that allow a user to write parse events to an XML output stream.
  3. 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.

This is the draft review specification. The Public review closes on 4th July 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr173/index.html

Proposed Final Draft Specifications

JSR-185 Java Technology for the Wireless Industry

Also see http://jcp.org/aboutJava/communityprocess/first/jsr185/index.html. This is an umbrella JSR that covers the use and relation of various other JSR's relating to the wireless industry. In particular, this JSR describes and overall architecture of how the various proposed wireless API technologies work together to form a complete handset solution for the wireless services industry. This JSR was updated with a list of other JSR's under the umbrella of this JSR and provides a reference to the Java Wireless Architecture Roadmap This also links to an Open letter from the Expert group describing the status and future of this JSR.

JSR-197 Generic Connection Framework Optional Package for the J2SE Platform

Also see http://jcp.org/aboutJava/communityprocess/first/jsr197/index.html. In order to support a generic mechanism of creating "connections" from small devices to other devices, networks or storage systems the Java Microedition Platform (J2ME) defines a "Generic Connection Framework" (JSR-46). This generic framework provides runtime protocol binding and an abstraction to creating connections hiding all the protocol, transport and network specific details from the application programmer. The Java Standard Platform (J2SE) support connections through a number of libraries and classes within the java.io and java.net package namespaces. This JSR intends to provide the Generic Connection Framework as implemented in J2ME to J2SE. This will allow complete and seamless portability of applications written from J2ME to J2SE.

JSR-160 JMX Remoting 1.2

Also see http://jcp.org/aboutJava/communityprocess/first/jsr160/index.html. Java Management Extensions (JMX, JSR-3) currently provides the means to create Java based management agents, through standardized techniques for instrumentation, and standardized agent services. But it does not standardize the means to access these agents remotely. There are no API's that define a common technique to connect to and access these management agents from remote machines. This JSR intends to define a Client interface for communicating with management agents thereby exposing a single interface to the client, hiding and abstracting the underlying tunneling and messaging protocol.

Resources:

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@jcpwatch.org.

Sitemap | Contact Us