Deel 1. Ik heb heel kort geschreven over annotaties van het type SOURCE en CLASS. Dit is het lezen waard, om te voorkomen dat je verdwaalt in het tweede deel en om je "misverstand" een beetje uit te breiden =) Ik beloof je dat er zeker minstens één woord zal zijn dat je kent!
De eerste keer dat ik annotaties in de taken hier zag, besteedde ik er op de een of andere manier niet veel aandacht aan. Er is hier en daar @Override, maar IDEA voegt dat toe, dus ik dacht dat het zo moest zijn. Na verloop van tijd besefte ik dat alles veel dieper is. Terwijl je studeert, lijken annotaties misschien wat nutteloos maar noodzakelijk. Je weet niet waarom ze bestaan of wat ze doen. Je hebt een paar artikelen gelezen waarin stond: "Het is zo geweldig dat we nu annotaties hebben, alles is zo eenvoudig geworden." Maar ik wist niet hoe de dingen vroeger waren, en ik begreep niet dat de dingen nu gemakkelijker zijn. Nu weet ik het wel en wil ik een beetje delen. Er zijn 3 soorten (RetentionPolicy) annotaties:
Inheems - ik heb dit nog nooit gezien en nooit gebruikt. Ik denk dat dit een nogal zeldzame annotatie is, omdat het wordt gebruikt wanneer je code in een andere "native" taal moet uitvoeren. Ik heb geprobeerd en gefaald om er een duidelijke vermelding van te vinden.
SuppressWarnings — Deze annotatie wordt vaak als volgt gebruikt: @SuppressWarnings("niet aangevinkt"). Het wordt gebruikt om waarschuwingen waarvan u al op de hoogte bent, te onderdrukken. Het vorige voorbeeld onderdrukt waarschuwingen over ongecontroleerde typeconversies. Nogmaals, dit is het enige gebruik dat ik ben tegengekomen.
Gegenereerd — Ik kom deze annotatie nu tegen vanwege een opdracht waarbij ik klassen moet genereren uit XSD-bestanden. Deze 3 annotaties zijn vrij specifiek en zijn op dit moment waarschijnlijk niet interessant voor u. Ik zal de laatste beschrijven.
Negeren - Je gebruikt het constant en het doet iets heel nuttigs. Bij het overschrijven van een methode is het gemakkelijk om een fout te maken zonder de hulp van IDEA. Of het nu gaat om typefouten of simpele fouten, fouten gebeuren. Deze annotatie zorgt ervoor dat de methode in de bovenliggende klasse overeenkomt met onze (geannoteerde) methode. Dit zorgt ervoor dat de methode wordt overschreven in plaats van toegevoegd. Bij het herstructureren van code kan de bovenliggende methode worden verwijderd of gewijzigd. Nogmaals, deze annotatie geeft een fout aan. Zonder dat zou onze methode gewoon worden toegevoegd. Saai? Ik zou Ja zeggen. Er is niet veel nuttigs uit dit artikel te halen. Vrijwel alles (90%) beschrijft hier iets dat je nooit of zeer zelden zult gebruiken. De overige 10% zegt hallo tegen en beschrijft de annotatie @Override, wat op het eerste gezicht nutteloos is. Dat gezegd hebbende, denk ik dat het tweede deel van het artikel interessanter zal zijn. Er zullen RUNTIME-annotaties worden besproken - ze communiceren met de code tijdens de uitvoering en doen zwarte magie. Annotaties. Deel 2. Lombok

- BRON — Annotaties voor de compiler
- KLASSE — Informatie van de annotatie wordt geschreven in bytecode, maar is niet beschikbaar tijdens runtime. Ze zeggen dat de standaardbibliotheek veel annotaties van dit type heeft, die nu worden bewaard voor achterwaartse compatibiliteit. Dit wordt gebruikt voor zeer specifieke taken.
- Vraag en antwoord op StackOverflow
- RUNTIME — Deze annotaties zijn het populairst. Ze worden gebruikt terwijl de code wordt uitgevoerd.
- java/lang/annotation/Native.class;
- java/lang/SuppressWarnings.class
- javax/annotation/Generated.class
- java/lang/Override.class
- com/sun/istack/internal/Nullable.class
- com/sun/istack/internal/NotNull.class
- com/sun/istack/internal/Interned.class
- Native — Een variabele met deze annotatie kan verwijzen naar native code;
- SuppressWarnings — Deze annotatie onderdrukt verschillende compilerwaarschuwingen;
- Gegenereerd - Deze annotatie markeert de broncode die is gegenereerd;
- Override — Deze annotatie controleert methode-overrides.
GO TO FULL VERSION