Java News from Tuesday, October 17, 2006

Sun has posted the early draft review of JSR-277, Java Module System to the Java Community Process (JCP). According to the draft,

Java Archives (JARs) are widely used as both the distribution format and the execution format for Java applications. The JAR file format dates back to the mid-1990s, and it has not scaled particularly well in either of these roles. JAR files are hard to distribute, hard to version, and hard to reference in general.

Distributing a simple Java application is considered to be a complicated task by many developers because it often involves creating a native installer to package multiple JAR files into a distribution unit, and it sometimes involves converting the application into a Java applet or JNLP (Java Network Launching Protocol) application for web-based deployment. The versioning support in the JAR file format is for expressing dependencies on Java extensions (a.k.a optional packages), but not the version of the JAR file itself. There is also no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR file upon another. Referencing a JAR file, moreover, involves specifying it in the classpath. Since the path of a JAR file may change during deployment, developers are forced to fix up all the references to the deployed JAR files as part of the deployment process.

Developers also find it quite difficult to deploy installed Java extensions because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations. The overall goal of the Java Module System is to define a solution that addresses the above issues.

The Java Module System defines an architecture with the following components:

The Java Module System is compatible with Java SE 7 or later.

Comments are due by November 13.


Sun has posted the proposed final draft of JSR-268 Java Smart Card I/O API to the Java Community Process (JCP). This defines the javax.smartcard package.


Sun has posted the proposed final draft of JSR-269, Pluggable Annotation Processing API to the JCP. The spec is pure JavaDoc, and I really wish they'd just put it up on a web site instead of making it a downloadable zip file. According to the JSR,

J2SE 1.5 added a new Java language mechanism "annotations" that allows annotation types to be used to annotate classes, fields, and methods. These annotations are typically processed either by build-time tools or by run-time libraries to achieve new semantic effects. In order to support annotation processing at build-time, this JSR will define APIs to allow annotation processors to be created using a standard pluggable API. This will simplify the task of creating annotation processors and will also allow automation of the discovery of appropriate annotation processors for a given source file.

The specification will include at least two sections, a section of API modeling the Java programming language and a distinct section for declaring annotation processors and controlling how they are run. Since annotations are placed on program elements, an annotation processing framework needs to reflect program structure. Annotation processors will be able to specify what annotations they process and multiple processors will be able to run cooperatively.

The processors and program structure API can be accessed at build-time; i.e. this functionality supplements core reflection support for reading annotations.

Comments are due by August 1.