Michael Nascimento Santos's Blog

First draft for Common Annotations is out

The first early draft for JSR-250, Common Annotations for the Java Platform, has been published. There are less than 10 annotations specified in this version, most of them related to security.

Although many other annotations will probably be added for the next versions, as part of the expert group I would like to request your feedback. Download the early draft and send us your comments. The best time to change a spec is at its early stages. Don't miss this opportunity.

UPDATE: please send your feedback to jsr-250-comments@jcp.org instead of posting a comment to this entry. Thanks!

Comments

• Here are some of the kinds of annotation that should have standards in JSR-250, but don't yet:

  Computational time required. One way to specify this would be Order notation AKA big O notation. It would help with problems like this.
  Thread safety. Just as threadsafety should be documented so that programmers can use objects appropriately, it should be expressed in standard metadata, so that tools can use it.
  Thread affinity. There needs to be a standard way of expressing restrictions like "This method can only be invoked on the event dispatch thread".
  Early null detection. While I strongly advocate adding Nice protection against null pointers to Java, a standard annotation is also needed.
  Design by contract. There are all sorts of other constructs from the DBC world that should have standard annotations.
  Mutability. Classes that declared themselves immutable could be checked for mutability by a tool. They could also be the target of runtime optimizations based on their immutability.
  Cloneable. Exactly what kind of clone is produced.
  

  Posted by: coxcu on March 29, 2005 at 06:35 AM

• 
  Actually I'm using a self written annotations processor in a big J2EE project. Besides others I found following annotations usefull enough to be defined as standard ones:

  - First: The counterpart to java.lang.Override.
  This annotation takes no value.
  Annotating a class by First results in a compiletime error for each
  method which overrides a non-abstract superclass method if the overwriting
  method is not annotated by java.lang.Override. Interfaces are not
  allowed to be annotated by First.
  This is usefull to ensure not to accidently overwrite a superclass method
  without having thought about. E.g. one team member edits the superclass,
  the other the subclass.

  - Implement: Annotation to mark methods that they have
  to be the implementation of a method of an interface implemented
  by the declaring class or of an interface implemented by one of its
  superclasses. This annotation takes no parameters.
  This is usefull especially on application level to locate methods which have
  become obsolete. The Implement annotation is similar to
  java.lang.Override with the difference it supports interface methods.

  - MandatoryConstructor: Annotation to mark classes that
  their non-abstract subclasses must declare a specific constructor. This
  annotation takes an array of classes as parameters to describe the
  constructor's parameter types.
  This is usefull for conventions relying on Java reflection.

  - A quiet complex package allows development of MBeans using runtime
  processed annotations. The annotations allow to define descriptions for
  MBean attributes and operation parameters, as well as a default JNDI name
  and some other stuff.
  A compile time processor ensures the annotations are used correctly. A
  runtime processor produces the DynamicMBean info.
  The MBeanInfo could theoretically also be generated at compilation time, but
  currently I've not found a way to manipulate source code without to tamper
  the information about source code position in stacktraces of exceptions. I am
  not willing to loose this debug info.
  I also have no control over the classloader, thus I can not use bytecode
  instrumentation.

  The feature I'm missing most in Apt is to process annotations of local variables. More precisely I would like to process every item of source files, such that I could not only process annotations but collect any information I want to. E.g. to check code conventions.

  I also miss a way to generate code without having to write the whole file. Java should have a standard API to manipulate the AST tree.
  

  Posted by: joergwassmer on March 29, 2005 at 08:31 AM

• What is it?
  The whole thing is hidden behind an unacceptable license; could you give us a global overview of what this is?

  Posted by: zander on March 29, 2005 at 12:08 PM

• Thread safety and thread affinity annotations would be useful.

  Posted by: prunge on March 29, 2005 at 03:04 PM

• I am using a self written annotation like processor (it uses interfaces like annotations, so that it works with 1.4):

  https://pec.dev.java.net/nonav/compile/index.html

  I have found design patterns to be useful annotations (see web site for list) and like the first post above find marking immutability very good.

  Posted by: hlovatt on March 29, 2005 at 03:06 PM

This work is licensed under a Creative Commons License.