I thought I'd catch up on the Java Community Process (JCP) today. Most significantly, Sun has posted the public review draft of Java Specification Request 176, J2SE™ 1.5 (Tiger) Release Contents, to the Java Community Process (JCP). No surprises here now that the Java 1.5 beta has been released.
There are also several; JSRs describing particular features of Java 1.5. The Public Review Draft Specification for JSR-200 Network Transfer Format for Java Archives describes the new Pack200 format for JAR archives. Sun claims compression factors of seven to nine when combined with a post-pack phase using a standard algorithm such as zip. Comments are due by February 14.
Joshua Bloch's and Gilad Bracha's public review draft specification for JSR-201, Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import describes most of the changes to the core language in Java 1.5. Comments are due by February 21.
Sun's Tim Lindholm has uploaded the public review draft specification for JSR 133, Java Memory Model and Thread Specification Revision. According to the draft, this spec "is intended to replace Chapter 17 of the Java Language Specification and Chapter 8 of the Java Virtual Machine Specification." I'm not particularly well-versed in the intimate details of Java's threading and memory models, so it's not immediately obvious to me what's changed here. read it for yourself if you're curious. William Pugh has posted a large collection of background information that went into this spec on his web site. Comments are due by March 7.
I don't think this is specifically part of J2SE 1.5, but Sun has posted the proposed final draft of Java Specification Request 127, Java Server Faces in the Java Community Process. Quoting from the web page,
JavaServer™ Faces technology simplifies building user interfaces for JavaServer applications. With the well-defined programming model that JavaServer Faces provides, developers of varying skill levels can quickly and easily build web applications by: assembling reusable UI components in a page, connecting these components to an application data source, and wiring client-generated events to server-side event handlers. With the power of JavaServer Faces technology, these web applications handle all of the complexity of managing the user interface on the server, allowing the application developer to focus on application code.
JavaServer Faces technology includes:
- A set of APIs for: representing UI components and managing their state, handling events and input validation, defining page navigation, and supporting internationalization and accessibility.
- A JavaServer Pages™ (JSP™) custom tag library for expressing a JavaServer Faces interface within a JSP page.
Nokia has submitted and the JCP executive committee for the Java 2 Micro Edition (J2ME) approved JSR-238, Mobile Internationalization API. Quoting from the JSR,
This specification will provide a common API for the internationalization of MIDP applications, delivered and licensed as an optional package. It will 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, e.g. for formatting dates, times, numbers, and currencies, and sorting text strings correctly for the user’s locale. The API needs to be memory-efficient to run on resource-constrained devices such as mobile phones.
Sun's posted a new maintenance review draft of JSR-28 Java SASL Specification. SASL stands for "Simple Authentication and Security Layer." It defines a protocol independent method for adding authentication support to connection-based protocols. SASL is defined in RFC 2222. RFCs 2245, 2444, and 2831 describe particular SASL mechanisms, while RFC 2554 describes SASL used with SMTP, and RFC 2829 describes SASL used with LDAP.
Sun's preparing a maintenance release of JSR 115, Java Authorization Contract for Containers. Comments are due by March 1. The proposed changes feel pretty minor.
IBM and BEA have jointly submitted Java Specification Request 236, Timer for Application Servers, to the JCP, and it's been approved for development. According to the JSR,
The Timer API for Application Servers provides a Timer API for use within managed environments such as application servers conforming to JavaTM 2 Enterprise Edition (J2EE), within components such as Servlets, EJBs, and JCA Resource Adapters. The Timer API enables applications to schedule timer and receive timer notification callbacks with an application-specified listener.
When with managed environments, this API is a much better alternative to java.util.Timer and the JMX Timer, the two standardized APIs in Java:
- java.util.Timer should never be used within managed environments, as it creates threads outside the purview of the container. Further, there is no clean way of subclassing java.util.Timer to avoid thread creation, as all constructors create and start a thread.
- The JMX Timer is tightly coupled with the JMX framework and does not provide a sufficiently user-friendly or independent API.
The J2EE Timer thus provides a clean, simple, independent API that is appropriate for use within any J2EE container.
IBM and BEA have also submitted Java Specification Request 237, Work Manager for Application Servers, to the JCP, and it's been approved for development. According to the JSR,
The Work Manager for Application Servers specification will contain an API that provides a simple, container-manageable programming model for concurrent execution of work. These work items execute out of a thread pool managed by a container. The Work Manager API provides a higher level of abstraction for concurrent programming than java.lang.Thread, which is inappropriate for use by applications hosted in managed environments such as EJB containers and Servlet containers.
This API can be used within any environment, but is specifically designed for the requirements of managed environments.
This specification does not require any changes to existing JavaTM 2 Enterprise Edition (J2EE) APIs or deployment descriptor formats. Components can access the work service through a lookup in the local Java environment in JNDI, provided the container supports this API and the application has been properly configured.
Independently,
IBM has released the maintenance update to
of Java Specification Request (JSR) 921,
Implementing Enterprise Web Services 1.1.
According to the introduction, "This specification defines the Web Services for J2EE architecture. This is a service architecture that leverages the J2EE component architecture to provide a client and server programming model which is portable and interoperable across application servers, provides a scalable secure environment, and yet is familiar to J2EE developers."
New features include support for anonymous types and xsd:any.
Sun's posted a maintenance update to JSR-914, the Java Message Service API.
This maintenance release addresses the unification of the programming interfaces for the Point-to-Point and Pub/Sub messaging domains in the Java Message Service (JMS) API. In the existing version of the specification, the client programming model make a strong distinction between these two domains. One consequence of domain separation is that actions from the Point-to-Point domain and the Pub/Sub domain in can not be used in the same transaction.
In this proposed domain unification of the interfaces, methods have been added to support the ability to include PTP and Pub/Sub messaging in the same transaction. In addition, the domain unification proposed simplifies the client programming model, so that the client programmer can use a simplified set of APIs to create an application.
I'm told this is backwards compatible with existing JMS programs.