Built-in Java Annotations

Java includes standard annotations that communicate intent and compiler-related constraints, mark deprecated APIs, control selected warnings, and provide metadata. Common examples include `@Override`, `@Deprecated`, and `@SuppressWarnings`.

Annotations are metadata attached to program elements such as classes, methods, fields, and parameters. They begin with `@` and can be interpreted by the compiler, development tools, frameworks, or runtime reflection depending on their definition and retention policy.

`@Override` tells the compiler that a method is intended to override a superclass or interface method. The compiler can then report an error if the method does not actually override anything, which helps catch mistakes such as an incorrect method signature.

`@Deprecated` marks an API as discouraged for new code. Java compilers and tools can warn when deprecated declarations are used, and the annotation can be accompanied by documentation explaining the preferred replacement.

`@SuppressWarnings` requests that the compiler suppress specified warning categories for a particular scope. It should normally be applied as narrowly as practical because suppressing warnings too broadly can hide useful diagnostic information.

Built-in annotations are distinct from reflection itself. Reflection can inspect annotations at runtime when the annotation's retention policy and target permit that use; an annotation does not automatically imply runtime availability.

Key points

• `@Override` lets the compiler verify an intended override.
• `@Deprecated` marks an API as discouraged for new usage.
• `@SuppressWarnings` suppresses specified compiler warnings within a scope.
• Annotations can be consumed by the compiler, tools, frameworks, or runtime reflection.
• Annotation retention determines whether metadata remains available at runtime.

Interview questions

What does `@Override` do in Java?

`@Override` tells the compiler that a method is intended to override an inherited method. The compiler checks that the method actually overrides a superclass or interface method. If the signature is wrong, compilation fails instead of silently defining an unrelated method. This makes the annotation useful for catching refactoring and spelling mistakes.

What is the purpose of `@Deprecated`?

`@Deprecated` marks a declaration as deprecated, indicating that new code should generally avoid relying on it. Java tooling can issue diagnostics when deprecated APIs are used. The declaration remains available unless it is separately removed or otherwise made inaccessible. Documentation can identify a replacement or explain migration guidance.

When would you use `@SuppressWarnings`?

I would use `@SuppressWarnings` when a known warning is intentional and has been reviewed. The suppression should be limited to the smallest reasonable scope so unrelated diagnostics remain visible. The warning category is supplied as a string, such as `deprecation` for deprecated API usage. Suppression should not replace fixing a warning when the underlying code can be improved.

How do annotations relate to reflection?

Annotations are metadata, while reflection provides APIs for inspecting program structure at runtime. An annotation can be visible through reflection if its retention policy includes runtime retention. For example, a framework can inspect a class and discover runtime-retained annotations on its methods. Compile-time-only metadata is not available through normal runtime reflection after compilation.

Why is `@Override` useful even when the program would compile without it?

The annotation turns an implicit intention into a compiler-checked contract. Without it, a changed superclass or interface signature can cause a method to stop overriding while leaving an apparently valid method in the subclass. With `@Override`, that mismatch becomes a compilation error. This is especially valuable during refactoring because it converts a potentially subtle behavioral defect into an immediate diagnostic.