This question is not about how heap pollution can occur. This question is not about what effect the annotation @SafeVarargs has. I understand that it is used to suppress warnings, both locally and at call sites. I read the documentation. My question is: why was this annotation added to the Java language at all?
Consider the following:
The absence of the annotation is not a useful distinction. There is never a situation where you could intend to use the VarArgs in an unsafe way, i.e. "UnsafeVarargs".
This differs from other annotations like @Override where the absence of the annotation is a useful distinction: "hey I don't intend to override any method in my superclass, warn me if somebody adds a method with the same signature to my superclass."
Either the programmers know how to use Varargs safely or they do not. If they add the annotation it does not change that. So isn't it just providing a false sense of security for callers?
This reminds me of the flawed notion that holding your car door handle up while closing the door will prevent you from locking your keys inside.
Continuing from point 2, wouldn't it be better to disable the warning globally by default, and then re-enable it globally when doing an extensive review?
Maybe I am missing something. Maybe the annotation plays a useful role when migrating from old versions of Java? I welcome your answers. Thanks.
Continuing from point 2, wouldn't it be better to disable the warning globally by default, and then re-enable it globally when doing an extensive review?
That sounds like a really bad thing for reality.
In reality, you strive for a zero tolerance policy. Zero waste in your code, zero warnings, zero errors, zero unit test fails. And you keep checking your "counts" all the time. You add 5 lines of code to your class; and that class gets an yellow ! (eclipse telling you about warnings in there) ... you go in and fix them - immediately. And not at some hypothetical future point in time when somebody happens to enable warnings globally.
In other words: you never ever even consider to disable warnings globally.
So, the other way round: there are occasions when the compiler can only detect: "there might be a problem" - and then the compiler better warns about that. But for situations where the programmer can reasonable assess the situation, such annotations are a simple, straight forward mean (working on really local scope!) to suppress that compiler warning.
But you are certainly correct in your assumption that a programmer who doesn't understand varargs might inadvertently use that annotation in an incorrect manner, too. A reasonable strategy to address could be: "have code reviews focus on code that uses this annotation" for example. Instead of globally disabling warnings.