I'll be away in Montreal next week for the Extreme Markup Languages conference. Depending on what Internet access is available at the Hotel, updates may be a little slow until I return.
Sun's posted the second change log for Java Specification Request (JSR) 924, Java Virtual Machine Specification. I'm not an expert an expert on virtual machine internals, but the changes appear to be substantive, not merely editorial like a lot other maintenance releases. Comments are due by August 23.
Joshua Bloch and Gilad Bracha have posted the proposed final draft specification for JSR-201, Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import. This describes most of the changes to the core language in Java 1.5 (with the notable exception of generics). I've done a little work with autoboxing and the enhanced for loops lately. I've decided I like enhanced for loops, but I'm still undecided about autoboxing. Also, kudos to the working group for the doing the spec in HTML instead of PDF. :-) If only they'd just post the damn files on a regular web site, instead of making you download a ZIP archive. :-(
Sun has posted the proposed final draft specification for JSR-226, Scalable 2D Vector Graphics API . "This API is targeted for low-end mobile devices with constraints in memory, screen size, and computational power. The goal of this specification is to define an optional API package for rendering Scalable 2D vector images, including external images in SVG format. The main target use cases of this API are map visualization, scalable icons and other applications which require scalable, animated graphics."
BEA Systems has published an early draft review of Java Specification Request 181, Web Services Metadata for the Java Platform. Quoting from the introduction to the draft,
This specification defines a simplified model for Web Services programming that is easy to learn and rapid to develop. The J2EE standard deployment technologies, APIs, and protocols require the J2EE developer to master a substantial amount of information. This JSR reduces the amount of information required to implement Web Services on J2EE by using metadata to declaratively specify the Web Services that each application provides. The metadata annotates the Java source file that implements the Web Service. While the metadata is human readable and editable using a simple text editor, graphical development tools can represent and edit the Java source file using higher levels of abstraction specific to Web Services. This is a simpler and more powerful development environment than traditional coding tools that are used to develop source code using low level APIs.
This specification relies on the JSR 175 specification, “A Program Annotation Facility for the JavaTM Programming Language”, for the Web Services metadata that annotates a Java WS file. This document is using JSR 175 features as described in the Public Draft Specification of JSR 175.
JSR 181 defines the syntax and semantics of Web Services metadata and default values to be used, but does not define a runtime or container environment. Instead, implementers are expected to provide tools that map the annotated Java classes onto a specific runtime environment. However while this specification does not constrain the Java environment on which Web Services are run, it assumes a J2SE1.5 compiler as well as the functionality of the J2EE 1.4 containers. In particular, JSR 181 expects features such as JAX-RPC 1.1 and JSR-109, along with the compiler and language extensions from JSR 175 to be present.
A JSR 181 implementation must produce a deployable Java Web Service application that can run on the target Java environment. The deployed application must exhibit the proper behavior described by the Web Services metadata and Java source code. Any two JSR 181 processors starting from the same valid annotated Java Web Services file will produce equivalent Web Service applications, even though they may deploy on very different Java environments. This ensures portability of JSR 181 compliant Java files.
Day Software has posted the public review draft specification for JSR-170, Content Repository for Java™ Technology API. According to the draft:
As the number of vendors offering proprietary content repositories has increased, the need for a common programmatic interface to these repositories has become apparent. The aim of the Java Content Repository (JCR) API specification is to provide such an interface and, in doing so, lay the foundations for a true industry- wide content infrastructure.
Application developers and custom solution integrators will be able to avoid the costs associated with learning the particular API of each repository vendor. Instead, programmers will be able to develop content-based application logic independently of the underlying repository architecture or physical storage.
Customers will also benefit by being able to exchange their underlying repositories without touching any of the applications built on top of them.
Werner Randelshofer has posted a beta of the Quaqua Look and Feel 2.0, an extension for Apple's implementation of the Aqua Look for Swing. According to Randelshofer, "Quaqua aims at fixing inconsistencies between user interface elements implemented in Swing and those of native Mac OS X applications. To achieve this, Quaqua selectively replaces UI elements of Apples Aqua Look And Feel with elements of its own." Quaqua is dual licensed using the BSD license and the LGPL.