Sun's posted a maintenance review draft of the Java Language Specification, Third Edition.
The Java Language Specification, 3rd Edition, has been revised as a result of generics (JSR 14), metadata (JSR 175), language additions (JSR 201), the assert statement (JSR 41 from Java 2 SDK 1.4), the revised memory model (JSR 133), and Unicode supplementary character support (JSR 204).
This Maintenance Review covers additional minor corrections and adjustments including clarifications to:
- floating point literals
- String operators
- private class members
- asserts in initialization
- handling the $ character in class names
- local class declarations
- the distinction between exception handling of expressions and statements
- caveats to interface type members
Comments are due by September 20.
Sun's Joshua Bloch has posted the second proposed final draft specification Java Specification Request (JSR) 175 A Metadata Facility for the Java Programming Language to the Java Community Process. According to the draft,
This document describes a simple program annotation facility for the Java programming language. This facility allows developers to define custom annotation types and to annotate fields, methods, classes, and other program elements with annotations corresponding to these types. These annotations do not directly affect the semantics of a program. Development and deployment tools can, however, read these annotations and process them in some fashion, perhaps producing additional Java programming language source files, XML documents, or other artifacts to be used in conjunction with the program containing the annotations. For example, a tool called a stub generator could generate remote procedure call stubs as directed by annotations indicating which methods were designed for remote use.
As another example of the sort of thing one could do with annotations, consider the familiar @deprecated tag. This tag does not affect the behavior of deprecated elements, but tells the compiler to emit warnings when annotated elements are used. The Javadoc tool also uses these annotations to generate appropriate documentation of the deprecated status of API elements. The deprecation facility was implemented in an ad hoc fashion using documentation comments, but could have been implemented atop a program annotation facility, had one existed at the time the deprecation facility was designed.
A second example of ad hoc program annotation already present in the Java platform is the transient modifier. The presence or absence of this modifier does not affect the semantics of a field, but it may be queried at runtime by the libraries that comprise the serialization subsystem as part of the serialization process. It is also queried at documentation generation time by the Javadoc utility as part of the process of generating documentation for the serialized form of the class.
Since many annotations will be used only by development tools such as stub generators, it makes little sense to retain all annotations at run time; doing so could increase run-time memory-footprint and harm performance. There are, however, some annotation types that are useful at run time, and some that are useful in tools that only have access to class files (not source files). Therefore, certain annotations are stored by the compiler in class file attributes (JVMS 4.7), and some of these annotations are then made available for inspection at runtime via new reflective APIs.
On a positive note, the specification is published in HTML rather than PDF like most Sun specs. Now if we could just convince Sun to make it available on the Web instead of forcing users to download a zip file. (And just to head off a frequent comment, this would in no way prevent Sun from enforcing license agreement as they do now. A document such as this can easily be a response to a POST request. Whether you should have to accept the license to read the document is another story, but there's no technical problem with it.)