Suppress Warnings safe varargs

We are going to add another Annotation above the main method. Within the

class JavaLangAnnotations {

We are going to add another Annotation above the main method.

@SuppressWarnings({"deprecation", "removal"})

In Java SE 22, the @SuppressWarnings({"deprecation", "removal"}) annotation is used to suppress specific compiler warnings related to deprecated APIs and APIs marked for removal. Here's a breakdown of its purpose:

"deprecation": This suppresses warnings about the use of deprecated classes, methods, or fields. Deprecated elements are those marked with the @Deprecated annotation, indicating they are outdated and may be removed in future releases, but are still functional.
"removal": This suppresses warnings about APIs that are not only deprecated but also marked for removal in a future release (typically using @Deprecated(since="version", forRemoval=true)). Such APIs are in a terminal deprecation phase, signaling imminent removal.

Purpose

Prevent Clutter: It silences compiler warnings for code that intentionally uses deprecated or soon-to-be-removed APIs, reducing noise in build outputs.
Enable Legacy Code: Allows developers to maintain or temporarily use older codebases reliant on deprecated APIs without being flooded with warnings.
Controlled Risk: Indicates that the developer is aware of the risks of using such APIs and has chosen to proceed, often as a temporary measure during migration.

Example

@SuppressWarnings({"deprecation", "removal"})
public void useDeprecatedAPI() {
    // Using a deprecated method
    OldClass.deprecatedMethod(); // No warning generated
}

Notes

Use this annotation judiciously, as suppressing warnings can hide important signals about code that needs updating.
It’s often a temporary solution while transitioning to newer APIs.
The annotation can be applied at the method, class, or variable level, depending on the scope of suppression needed.

This annotation is particularly relevant in Java SE 22, as the platform continues to evolve, deprecating older APIs and preparing for their removal to maintain a modern, secure ecosystem.

SuppressWarnings and SafeVarargs

To understand the reasons for the @SafeVarArgs annotation, you have to understand the problem, which starts with some definitions.

1. A reifiable type is a type of one of the following: a) primitive, b) non-generic type, c) raw type or an invocation of a type with unbound wildcards. This is a type that loses no information during the type erasure process.
2. A non-reifiable type is a type who is type parameter information is lost by type erasure and includes invocations of generic types that are not defined as unbounded wildcards.
3. Heap pollution occurs when a variable of a parameterized type refers to an object that is not of that parameterized type.
4. In unchecked warning is generated if the correctness of an operation involving a parameterized type cannot be verified. This occurs if you mix raw types and parameterized types, or when performing unchecked casts.
5. Varargs - you will remember that varargs stands for variable arguments in a parameter of a method declaration. The varargs parameter is translated by the compiler into an array.
6. You need to also remember that you cannot create an array of parameterized types. You can however specify a varargs declaration with a parameterized type (non-reifable type).

SuppressWarnings and SafeVarargs

It is this discrepancy of being able to declare varargs with a parameterized type, and arrays having no support for parameterized types that leads to the possibility of heap pollution, since the varargs will get translated to a non-parameterized type array and not a parameterized type array.

Create a new class called SafeVarArgsExample We are making the array a reified type.

// Generic Array creation is not allowed
MyClass[] myArray = {
		new MyClass<>("Irmgard"),
		new MyClass<>("Bruno")
};

You use the @SafeVarargs annotation when you can safely assert that the implementation of the method will not throw a ClassCastException or other similar exception due to improper handling of the varargs formal parameter.
The @SafeVarargs annotation is a documented part of the method’s contract (it will be included in the Java docs API).
This annotation asserts that the implementation of the method will not improperly handle the varargs formal parameter. This annotation is considered more desirable than

@SuppressWarnings({“unchecked”,”varargs”});

Java SE 22 (and earlier versions since Java 5) supports varargs notation (`...`) in generic methods, with some important caveats due to type erasure and potential heap pollution.
Let us walk through how this works and its limitations.

Syntax: Using Varargs in Generics

You can write a generic method that uses varargs like this:

@SafeVarargs
public static <T> void printAll(T... elements) {
  for (T element : elements) {
    System.out.println(element);
  }
}

You can call it like:

printAll("Apple", "Banana", "Cherry");
printAll(1, 2, 3, 4);

Type Safety Concerns

When you use varargs with generics, you might trigger heap pollution, because arrays and generics don't mix well due to type erasure.

public static <T> void unsafeMethod(T... values) {
 Object[] array = values; // allowed
  array[0] = "This is not a T"; // compiles fine
 T t = values[0]; // ClassCastException at runtime
}

@SafeVarargs Annotation
- To suppress unchecked warnings when you're confident the method is safe, annotate it with @SafeVarargs. This can only be used on:

static methods
final instance methods
private instance methods (since Java 9)

@SafeVarargs
public static  void safeMethod(T... items) {
    for (T item : items) {
        System.out.println(item);
    }
}

If you try to use it on a non-final instance method, the compiler will reject it.
📌 Summary

Feature	Supported in Java SE 22?	Notes
Generic methods with varargs	✅ Yes	Use `T...` syntax
Type-safe by default	❌ No	Risk of heap pollution
`@SafeVarargs` annotation	✅ Yes	Required to suppress unchecked warnings