At a presentation a number of years ago given by Josh Bloch he made a comment that Java as a language hit the "sweet spot" of programming. His metaphor was based around the fact that the language was straightforward to learn and that rather than containing many esoteric coding constructs, writing and understanding a Java program was a relatively easy task.

I think Java is at a very critical point at the moment where it is slipping away from its sweet spot and this worries me. Two things are to blame: annotations and aspects.

An annotation allows a programmer to flag a part of a program with @ statements that at first glance are a glorified comment. A developer can define his or her own annotation that has typed properties and validation rules about where it can be used in code, both of which the compiler enforces. What you do with annotations is up to you, but a good example could be to formally flag which methods were fixed in a particular release, by whom, and why. For example, with an annotation called Mod you could write code like:

@Mod(bugNumber=5477,fixedBy="Fred");
public void foo(){
   ...
}

This is better than putting the details in a comment // Fixed by Fred for 5477 because programs can use the java.lang.reflect API to query classes and methods for the presence of annotations, so a report of fixes done by Fred could be written.

The problem occurs when an annotation is more than a glorified comment and contains information that is an instruction to the program itself. EJB 3.0 has fallen desperately foul of this and I saw some horrid sample code recently:

@Stateless
@Remote(Example.class)
public class ExampleBean implements Example
{
   @PermitAll
   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
   public String getName(int id)
   {
   // Method body here
   }
   @RolesAllowed({"administrator","power_user"});
   public void deleteName(int id)
   {
   // Method body here
   }

What has occurred is, basically, a ton of semantic program details about how the EJB should be deployed that used to be provided in the deployment descriptor has been slammed into the class as annotations. It is way, way wide of the sweet spot and looks more like a cross between a set of assembler op-codes mixed with some kind of fourth generation language syntax. Whatever it is, it isn't Java.

Kent Beck once said that having lots of classes and lots of methods is basically what good OO is about. Design Patterns, the bible of good OO practice, espouses patterns such as the strategy and mediator that encourage and teach the strength and power of separation. By contrast, the EJB specification actually boasts the fact that having everything defined in a single file is a good thing. Separate XML wasn't great but what would have been wrong with just moving from XML to something akin to BeanInfo where the logic and rules were held in Java code elsewhere?

This segues nicely into aspects. At the first presentation I saw on the subject I was told that the raison d'etre for their existence is so that only a single source file has to be touched to implement a piece of functionality. While I understand this as a goal, it just isn't really practical to make this your overriding goal and then jump through hoops to ensure that this is the focus of all your development. In my experience, with all but the most trivial change, to fix a bug or implement a feature you need to change several classes, perhaps an interface or two, and hopefully do some refactoring along the way to improve the overall system entropy. There is nothing wrong with good old-fashioned programming like this and, when I encounter aspects, I see a group of people driven with a zeal to do differently. Instead they code files that contain sets of instructions to a preprocessor that will go and modify the existing multiple files that you should have fixed by hand in the first place. As with annotations, there are good uses of aspects, namely introducing logging behavior, performing code metrics, or coding rule enforcement. Too far beyond this and they just become clever magic that is both confusing and silly. Aspect fever seems to be riding the hit parade at the moment as the silver-bullet answer to everyone's problem.

What both annotations and aspects bring to Java is some kind of powerful dark magic where source is now littered with semantic fluff disguising itself as something more trendy but wielding terrible power. What you write is no longer what gets run - someone else's preprocessor mangles it, clever code obscures this fact from you while you debug it, and rather than the JVM just executing the bytecodes from the source you wrote, there is now some kind of execution inference engine analyzing formalized comments to determine the code path instead.

I fear the worst for the language. Pandora's box has been opened, Java coding no longer has any rules to govern it, and muggle programmers are no longer safe.