public @interface Const {
}
```
Now consider the following class that uses this annotation:
```java
public class ShoppingCart {
...
public void addItem(@Const Item item) {
}
public void removeItem(@Const Item item) {
}
@Const
public float getTotal() {
return 0;
}
}
```
The annotation processor would consume the `@Const` annotations to produce compile-time errors for any attempts to modify an item while adding or removing from a shopping cart or any attempts to modify the state of shopping cart while querying for the total.
Okay, the language extension using `@Const` is only a _theoretical possibility_, since I don't think it will be of much practical value unless the core Java classes and existing libraries adopt this annotation type and its semantics. Nevertheless, it is an _interesting theoretical possibility_.
### Structural modifications
These extensions modify the structure of the program without modifying the behavior. For example, we could use a `@Property` annotation to mark fields of a class as properties. An annotation processor then processes the annotations to add a getter method and/or a setter method for each property based on whether it is a read-write, read-only, or write-only property. Essentially, with this extension, you get the property feature support similar to the one in [Groovy](http://groovy.codehaus.org/Groovy+Beans) and [C#](http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_10_6.asp).
Consider the following annotation type and the associated enumeration type:
```java
public @interface Property {
public PropertyKind value() default PropertyKind.ReadWrite;
}
```
```java
public enum PropertyKind {
ReadWrite, ReadOnly, WriteOnly;
}
```
Now consider the following class:
```java
public class Person {
@Property(ReadOnly) private long id;
@Property private String name;
}
```
The annotation processor would consume the `@Property` to translate this class into a byte-code equivalent of the following snippet:
```java
public class Person {
@Property(ReadOnly) private long id;
@Property private String name;
public long getId() {
return this.id;
}
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
```
If a getter or setter already existed for a property, the annotation processor would leave it untouched.
We can use the same idea to support certain structural design patterns directly into the extended language. For example, we can implement the [singleton pattern](http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html) by allowing classes to be marked with an annotation. Consider the following annotation and enumeration types:
```java
public @interface Singleton {
public SingletonKind value() default SingletonKind.Lazy;
}
```
```java
public enum SingletonKind {
Lazy,
Eager;
}
```
Now consider a class marked with a `@Singleton` annotation:
```java
@Singleton(Lazy)
public class Service {
public void serve() {
}
}
```
The annotation processor will translate this class into a byte-code equivalent of the following snippet:
```java
@Singleton(Lazy)
public class Service {
private static Service _instance;
public static Service instance() {
if(_instance == null) {
_instance = new Service();
}
return _instance;
}
private Service() {
}
public void serve() {
...
}
}
```
The annotation processor could also modify compile-time behavior to flag the presence of unsupportable structures such as non-zero arguments constructors.
### Behavior modifications
These extensions alter the program behavior. For example, they may add additional code to implement security feature in all the program elements with a `@Secure` annotation. EJB 3.0 annotations essentially extend the Java language in the same vein. Another good example of this kind of extension is [ContractJ](http://www.contract4j.org) that implements DBC in Java.
While implementing behavior modifications through language extension can be useful in some situations, aspect-oriented programming is a much better way to do the job. When implemented using AOP, the behavior logic doesn't disappear into code in an annotation processor, the code expressed remains much more readable, and the debugging process remains natural.
## Extension implementation
While some of the features described here can be implemented through a pre-processor (generating code) or post processor (modifying byte-code), a more convenient way would be to allow plugins to the compiler. It would not be surprising if a future tool's JSR proposes a standard way to extend the compiler (perhaps called "complet", in the same spirit as "doclet" to use with Javadoc). Perhaps the Pluggable Annotation Processing API (JSR 269) might be the one to standardize such a facility.
## Impact on Java
This possibility allows incorporating new features in the language without having to wait for them to make it into the standard. However, abusing this possibility can wreak havoc on the comprehensibility of the programs. Using this possibility to create principled extensions will make Java a more expressive language. AOP systems using annotations to add aspect-oriented features to Java is a good example of principled extensions (in that there is a system behind it -- aspect-oriented programming). Using this possibility to add ad hoc extensions, on the other hand, will make programs hard to follow without the context of the associated annotation processing.
How the community uses the metadata feature in general, and the language-extension use case in particular, will be interesting to watch.