Java annotations refer to a special kind of metadata that resides inside your Java source code files. They are not stripped by javac so that they can remain available to the JVM at runtime.

Annotations look similar to JavaDocs references because they start with the @ symbol. There are three types of annotations. Let's examine each of these as follows: 

• The most basic form of annotation is a marker annotation. These are standalone annotations, with the only component being the name of the animation. Here is an example:

@thisIsAMarkerAnnotation
public double computeSometing(double x, double y) {
     // do something and return a double
}

• The second type of annotation is one that contains a single value, or piece of data. As you can see in the following code, the annotation, which starts with the @ symbol, is followed by parentheses containing data:

@thisIsAMarkerAnnotation (data="compute x and y coordinates")
public double computeSometing(double x, double y) {
     // do something and return a double
}

An alternative way of coding the single value annotation type is to omit the data= component, as illustrated in the following code:

@thisIsAMarkerAnnotation ("compute x and y coordinates")
public double computeSometing(double x, double y) {
     // do something and return a double
}

• The third type of annotation is when there is more than one data component. With this type of annotation, the data= component cannot be omitted. Here is an example:

@thisIsAMarkerAnnotation (data="compute x and y coordinates", purpose="determine intersecting point")
public double computeSometing(double x, double y) {
     // do something and return a double
}

So, what has changed in Java 9, 10, and 11? To answer this question, we need to recall a couple of changes introduced with Java 8 that impacted Java annotations:

• Lambda expressions
• Repeated annotations
• Java type annotations

These Java 8-related changes impacted Java annotations but did not usher in a change to how javac processed them. There were some hardcoded solutions that allowed javac to handle the new annotations, but they were not efficient. Moreover, this type of coding (hardcoding workarounds) is difficult to maintain.

So, JEP 217 focused on refactoring the javac annotation pipeline. This refactoring was all internal to javac, so it should not be evident to developers.