Warning for generic varargs

Question

I have declared the following method:

private void mockInvokeDBHandler(Map<String, Object>... rows) {
    List<Map<String, Object>> allRows = Arrays.asList(rows));
    // rest of method omitted
}

It is invoked by clients using something like

Map<String, Object> row1 = new HashMap<String, Object>();
Map<String, Object> row2 = new HashMap<String, Object>();

mockInvokeDBHandler(row1, row2);

However, the last line shown above generates a warning

Type safety : A generic array of Map is created for a varargs parameter

I don't fully understand this, but I guess it's because varargs params are converted to arrays, and it's a bad idea to have an array whose type is a generic class (because generics are invariant, whereas arrays aren't).

I could resolve this problem by redifining the method as

private void mockInvokeDBHandler(List<Map<String, Object>> rows) {
}

But this places the burden of putting the row objects into a List on the client, which I'd rather avoid. Is there a better solution?

I'm sure your actual code compiles but it seems you have a posting error here: `ListMap allRows`, as it should be `List> allRows` — Mark Elliot, Nov 23 '10 at 15:59
@Mark E - thanks, the code is fine, just made a typo in my posting — Dónal, Nov 23 '10 at 16:08

score 12 · Accepted Answer · answered Nov 23 '10 at 15:59

To pass the arguments to a varargs method the compiler will place the arguments into an array.

The warning is to let you know that the compiler cannot guarantee that each of the elements in the array - each of the arguments to the varags method - is truly a Map<String, Object>.

This is a bit of an annoying warning because there is no way you can work around this, other than to redefine the method signature to not use varargs. IMO it is safe to ignore as long as you are pretty sure of the actual run-time types of these arguments (which in this case, you are).

score 4 · Answer 2 · answered Nov 23 '10 at 16:00

There's no way to avoid this warning, other than adding @SuppresWarning("unchecked") to the method :)

Since you say it's a private method there's no "clients" in this case and you're in control of the method, so ignoring the warning seems reasonable.

A few times when I've created methods taking parameterized types as a varargs parameter, I've created some overloads:

void mockInvokeDBHandler(Map<String, Object> map1)
void mockInvokeDBHandler(Map<String, Object> map1, Map<String, Object> map2)
void mockInvokeDBHandler(Map<String, Object> map1, Map<String, Object> map2, Map<String, Object>... othermaps)

That could avoid some of the warnings, depending on how many arguments are supplied.

Avoiding this kind of overloading is precisely the reason why I want to use varargs — Dónal, Nov 23 '10 at 16:09

score 4 · Answer 3 · answered Aug 02 '17 at 05:09

For anyone landing here, the answers are a little old. Java 7 introduced the @Safevarargs annotation to address this:

@SafeVarargs
private void mockInvokeDBHandler(Map<String, Object>... rows) {

From the javadoc:

A programmer assertion that the body of the annotated method or constructor does not perform potentially unsafe operations on its varargs parameter. Applying this annotation to a method or constructor suppresses unchecked warnings about a non-reifiable variable arity (vararg) type and suppresses unchecked warnings about parameterized array creation at call sites.

And the method must be effectively final – boot-and-bonnet Jun 05 '20 at 02:27 — boot-and-bonnet, Jun 05 '20 at 02:27

sfussenegger · Answer 4 · 2010-11-24T09:33:56.273

You could lower the burden of using a List instead of varargs by using some builder interface (e.g. like the one I'm using). Using this CollectionBuilder, it would become something like this:

mockInvokeDBHandler(CollectionBuilder.<Map<String, Object>>list().add(map1).add(map2).get());

it's prettier without generic args though:

import static at.molindo.utils.collections.CollectionBuilder.list

List<String> list = list(String.class).add("foo").addAll(set).get();

It's certainly longer as the varargs solution, but anyway pretty handy at times.

Warning for generic varargs

4 Answers4

Linked