Consider this TypeScript snippet. It's a very simple Angular2 component. It looks almost like a Java class, doesn't it?

My First Angular 2 App

In particular, the @Component looks like a Java annotation. In fact, it plays the some role as a Java annotation. It tells the Angular2 framework that this class is not an ordinary POJO, but something special. It's a component, one of the building blocks of Angular.

Striking similarity

That's exactly the same thing I already knew from the Java world. @Named converts a POJO into a CDI bean. Sometimes Java annotations even have the same fancy curly braces syntax:

So why do the JavaScript and TypeScript communities insist on calling their annotations "decorators"?

Decorators decorate!

The answer is simple: Decorators are called decorators because that's what they are. You can use them as annotations. But in reality, they are function calls. The Angular2 framework contains a function called Component() that takes a function as a parameter and returns another function. The @ of @Component tells TypeScript and EcmaScript 2016 to call the Component() function and to pass it the function after the decorator. Usually decorators are used to add functionality to a function.

AOP

Does this ring a bell? Exactly - that's more or less the same as aspect oriented programming. In fact, AOP is one of the classical use cases of Java annotations. Just think of @transactional. This annotation surrounds a method with the glue code needed to execute it in a transaction. In other words, it adds some code before executing the method (opening a transaction) and it adds code after the method (committing the transaction, or rolling it back).

Oops!

Making the @ symbol an alternative way to call functions is a very elegant way to implement both static annotations and AOP. Plus, it should be possible to pass variables as additional parameters. In Java, annotations only support constants that can be resolved a compile time, and every once in a while, that's a nuisance.

In hindsight, it's hard to understand why the Java team added simple annotations instead of full-blown decorators to Java 5. I suppose they didn't want to add a complex multi-purpose tool. Annotations can be used for exactly one purpose. They resemble a comment. They rely on a framework to be useful. This framework can be the editor, the compiler or the runtime environment. Only a few years later the JavaScript world showed how useful decorators are.

Can decorators be added to Java?

Sure. Java 8 introduced default methods. So we could define a default method in an annotation class and execute it when the annotated method is called. We'd have to consider a couple of corner cases, though. Annotations can be applied to classes, static fields, class attributes and method parameters. We'd have to define useful semantics for each of these corner cases. But that's not a big deal.

Wrapping it up

However, I don't think this will ever happen. Annotations have become such an important part of the Java world it's unlikely anybody takes the risk. So, for now, we can only marvel at the way the language designers took the syntax of the annotation and converted it into something even more useful. By the way, the flexibility of the JavaScript language allows for some tricks Java developers can only dream of. Only - Java applications tend to be a lot bigger than JavaScript applications, so this dreams would quickly turn into a nightmare. Nonetheless, the article I've linked in the "dig deeper" section is very interesting, and it's full of surprises - at least for a programmer like me spending most of their day in the Java ecosystem.

Dig deeper

Exploring EcmaScript 2016 decorators in detail