Antwoord

Annotaties werden toegevoegd in Java 5 om metadata te bieden die door de compiler en verschillende frameworks kan worden gebruikt. Aanvankelijk hielpen ze tools (zoals JUnit of Hibernate) om beter samen te werken met de code zonder dat er herhalende of externe configuratie geschreven moest worden.

Annotaties maken het mogelijk om informatie toe te voegen aan klassen, methoden, velden, parameters en zelfs lokale variabelen. Tijdens de compilatie, runtime of tijdens de verwerking van de broncode kunnen ze worden gebruikt voor validatie, het genereren van aanvullende bestanden, of het veranderen van het gedrag van het programma.

Om een eigen annotatie te declareren, wordt het sleutelwoord @interface gebruikt.

Voorbeeldcode:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MyAnnotation {
    String value();
}

class Example {
    @MyAnnotation("Test")
    public void annotatedMethod() {}
}

Belangrijke kenmerken:

Annotaties kunnen parameters hebben (met beperkte types)
Annotaties kunnen verschillende reikwijdte hebben (SOURCE, CLASS, RUNTIME)
Je kunt eigen annotaties maken om de standaardfunctionaliteit uit te breiden

Vragende met een valstrik.

Hebben annotaties alleen invloed op de runtime?

Nee, annotaties kunnen beperkt zijn tot de broncode (SOURCE), bytecode (CLASS) of beschikbaar zijn tijdens de uitvoering (RUNTIME). Hun invloed hangt af van de RetentionPolicy.

@Retention(RetentionPolicy.SOURCE)
public @interface SourceOnly {}

Kunnen de parameters van een annotatie van elk type zijn?

Nee, de toegestane types zijn alleen primitieve types, strings, enumeraties, andere annotaties en arrays van deze types. Objecten kunnen niet worden gebruikt.

Kunnen annotaties geërfd worden?

Strikt genomen worden annotaties niet geërfd zoals klassen. Een uitzondering is de annotatie met @Inherited, die alleen van toepassing is op afgeleide klassen (zonder invloed op methoden).

Veel voorkomende fouten en antipatronen

Verkeerd gebruik van de volgorde van retention en target
Ontbreken van documentatie bij het maken van aangepaste annotaties
Overmatige annotatie, die het onderhoud van de code bemoeilijkt

Voorbeeld uit de praktijk

Negatief geval

Een ontwikkelaar in een groot project heeft tientallen verschillende annotaties gemaakt voor testautomatisering, zonder deze te beschrijven, te documenteren en hun reikwijdte te beperken. Als gevolg daarvan was het voor een nieuw teamlid moeilijk te begrijpen welke annotaties waar werkten.

Voordelen:

Flexibele automatisering
Mogelijkheid voor verdere uitbreiding

Nadelen:

Verwarring bij het onderhouden van code
Toegenomen complexiteit bij het opleiden van nieuwe medewerkers

Positief geval

Het team implementeerde een strikte strategie voor het schrijven van eigen annotaties: ze voegden alleen noodzakelijke annotaties toe, beschreven elke annotatie gedetailleerd en beperkten hun reikwijdte.