java warning: Varargs method could cause heap pollution from non-reifiable varargs parameter

None of the answers I've seen on this question seem to me to be satisfactory so I thought I'd take a stab at it.

Here's the way I see it:

1. @SafeVarargs

• Suppresses the warning: [unchecked] Possible heap pollution from parameterized vararg type Foo.
• Is part of the method's contract, hence why the annotation has runtime retention.
• Is a promise to the caller of the method that the method will not mess up the heap using the generic varargs argument.

2. @SuppressWarnings("varargs")

• Suppresses the warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter bar.
• Is a cure for problems occurring within the method code, not on the method's contract, hence why the annotation only has source code retention.
• Tells the compiler that it doesn't need to worry about a callee method called by the method code messing up the heap using the array resulting from the non-reifiable varargs parameter.

So if I take the following simple variation on OP's original code:

class Foo {
    static <T> void bar(final T... barArgs) {
        baz(barArgs);
    }
    static <T> void baz(final T[] bazArgs) { }
}

The output of $ javac -Xlint:all Foo.java using the Java 9.0.1 compiler is:

Foo.java:2: warning: [unchecked] Possible heap pollution from parameterized vararg type T
    static <T> void bar(final T... barArgs) {
                                   ^
  where T is a type-variable:
    T extends Object declared in method <T>bar(T...)
1 warning

I can make that warning go away by tagging bar() as @SafeVarargs. This both makes the warning go away and, by adding varargs safety to the method contract, makes sure that anyone who calls bar will not have to suppress any varargs warnings.

However, it also makes the Java compiler look more carefully at the method code itself - I guess in order to verify the easy cases where bar() might be violating the contract I just made with @SafeVarargs. And it sees that bar() invokes baz() passing in barArgs and figures since baz() takes an Object[] due to type erasure, baz() could mess up the heap, thus causing bar() to do it transitively.

So I need to also add @SuppressWarnings("varargs") to bar() to make that warning about bar()'s code go away.

An additional (and quite superfluous-looking) @SuppressWarnings( "varargs" ) is needed to suppress the warning, as follows:

@SafeVarargs
@SuppressWarnings( "varargs" )
final void varargsMethod( Collection<T>... varargs )
{
    arrayMethod( varargs );
}

In fact you should not write your code in this way. Consider the following example:

import java.util.*;

class Test<T extends Throwable>
{
    @SafeVarargs
    @SuppressWarnings("varargs")
    final void varargsMethod( Collection<T>... varargs )
    {
        arrayMethod( varargs );
    }

    void arrayMethod( Collection<T>[] args )
    {
        Object[] array = args;
        array[1] = new Integer(1);
        //
        //ArrayList<Integer> list = new ArrayList<>();
        //list.add(new Integer(1));
        //array[1] = list;
    }

    public static void main(String[] args)
    {
        ArrayList<Exception> list1 = new ArrayList<>();
        ArrayList<Exception> list2 = new ArrayList<>();
        (new Test<Exception>()).varargsMethod(list1, list2);
    }
}

If you run the code, you will see an ArrayStoreException because you put an Integer into a Collection<T> array.

However, if you replace array[1] = new Integer(1); with the three comment lines (i.e. to put an ArrayList<Integer> into the array), due to type erasure, no exception is thrown and no compilation error occurs.

You want to have a Collection<Exception> array, but now it contains a ArrayList<Integer>. This is quite dangerous as you won't realise there is a problem.