Generic Wildcard Types Should Not Be Used in Return Parameters

Generic wildcard types should not be used in return parameters

The main benefit of using wildcard types, say in method formal parameter, is to provide flexibility to the user to pass, say any type of Collection, or List or anything that implements Collection (assuming that the collection is declared like Collection<?>). You would often find yourself using wildcard types in formal parameters.

But ideally you should avoid using them as return type of your method. Because that way, you would force the user of that method to use wildcard types at the caller end, even if they didn't want to. By using wildcard types, you're saying that, hey! this method can return any type of Collection, so it's your job to take care of that. You shouldn't do that. Better to use bounded type parameter. With bounded type parameter, the type will be inferred based on the type you pass, or the target type of the method invocation.

And here's a quote from Effective Java Item 28:

Do not use wildcard types as return types. Rather than providing
additional flexibility for your users, it would force them to use
wildcard types in client code.

Properly used, wildcard types are
nearly invisible to users of a class. They cause methods to accept the
parameters they should accept and reject those they should reject. If
the user of a class has to think about wildcard types, there is
probably something wrong with the class’s API.

Java wildcard generic as return warning in Eclipse and SonarQube

So how can I fix this warning ?

You can use a type parameter for your class :

public class GridModelHolder<T> {
   private List<T>  gridModel;

   public List<T> getGridModel() {
    return gridModel;
   }
}

The client code can then decide what type of List GridModelHolder holds :

GridModelHolder<String> gridModelHolder = new GridModelHolder<String>(new ArrayList<String>);

However, if you insist on using raw types, you can either suppress the warnings or simply have a List of objects (Neither of these are recommended)

@SuppressWarnings("unchecked")
public class GridModelHolder {
   private List  gridModel;

   public List getGridModel() {
    return gridModel;
   }
}

OR

public class GridModelHolder {
   private List<Object>  gridModel;

   public List<Object> getGridModel() {
    return gridModel;
   }
}

Generic wildcards in return types - how to avoid?

Probably there's a misunderstanding.

Let's have a look at

public void someMethod(SomeType<?> param) { ... }

This method accepts a parameter param which has to be of the parameterized type SomeType but the method doesn't mind the type parameter (put casually). That is, you can call this method with any parameter of type SomeType regardless of the used type parameter.

So, you can create your objects with a concrete type parameter and hand it over to the method, for example

public class Test<T> {
    public static void main(String[] args) {
        print(newTestString());
        print(newTestLong());
    }

    public static void print(Test<?> someTest) {
        System.out.println(someTest);
    }

    public static Test<String> newTestString() {
        return new Test<String>();
    }

    public static Test<Long> newTestLong() {
        return new Test<Long>();
    }
}

Update

The misunderstanding was at my side as it's about a generic type of a generic type. That's a different story. In the example the type is an Iterable which is parameterized by SomeType<?>. The problem is, that Iterable<SomeType<String>> is not a subtype of Iterable<SomeType<?>>.

The method would have to accept e. g. a parameter of type Iterable<? extends SomeType<?>> to be able to pass a Iterable<SomeType<String>>.

As the method is given the way it is, you'll have to work around.

(EDIT: deleted crap I wrote)

I would either not factor out the creation of the object or suppress the warning in that case.

Why can't I use the wildcard (?) as type of parameter, field, local variable, or as return type of a method?

The tutorial is terribly phrased. You cannot use a wildcard for any of the things listed. You can use a generic type with a wildcard in it for those things.

public class Example {
    ? field1;        // invalid
    List<?> field2;  // valid

    private ? method1(? param) {return param;}              // invalid
    private List<?> method2(List<?> param) {return param;}  // valid

    private void method3() {
        ? var1;        // invalid
        List<?> var2;  // valid
    }
}

Why I cannot use wildcard type in parameter to compute

The first method does not compile because of "capture conversion", that happens at each declaration. You can read my other answer about this, or this one. But to put it simply, you will have two separate types there, which you can see when you compile via:

 javac --debug=verboseResolution=all

And the output will contain:

.....
CAP#1 extends Object from capture of ?
CAP#2 extends Object from capture of ?
...

which means there are two types that have been capture converted. These types are unrelated to each other, the way you have it.

This on the other hand:

public static <T> void nothing(Collection<T> c){

}

is called wildcard capture method (it "captures" a wildcard) and is documented in official tutorial on why it works and how; thus you have no problem with that.

---

But the main problem here is that you can't assign anything (other than null) to a wildcard. So in your compute example, the first argument is going to be inferred to a ? and you can't assign anything to that.

When to use generic methods and when to use wild-card?

There are certain places, where wildcards, and type parameters do the same thing. But there are also certain places, where you have to use type parameters.

1. If you want to enforce some relationship on the different types of method arguments, you can't do that with wildcards, you have to use type parameters.

Taking your method as example, suppose you want to ensure that the src and dest list passed to copy() method should be of same parameterized type, you can do it with type parameters like so:

public static <T extends Number> void copy(List<T> dest, List<T> src)

Here, you are ensured that both dest and src have same parameterized type for List. So, it's safe to copy elements from src to dest.

But, if you go on to change the method to use wildcard:

public static void copy(List<? extends Number> dest, List<? extends Number> src)

it won't work as expected. In 2nd case, you can pass List<Integer> and List<Float> as dest and src. So, moving elements from src to dest wouldn't be type safe anymore.
If you don't need such kind of relation, then you are free not to use type parameters at all.

Some other difference between using wildcards and type parameters are:

• If you have only one parameterized type argument, then you can use wildcard, although type parameter will also work.
• Type parameters support multiple bounds, wildcards don't.

• Wildcards support both upper and lower bounds, type parameters just support upper bounds. So, if you want to define a method that takes a List of type Integer or it's super class, you can do:

  public void print(List<? super Integer> list)  // OK
  

  but you can't use type parameter:

   public <T super Integer> void print(List<T> list)  // Won't compile
  

---

References:

• Angelika Langer's Java Generics FAQs

Avoiding Returning Wildcard Types

Here's a type-safe way to store multiple instances of a given type in a map. The key is that you need to provide a Class instance when retrieving values in order to perform runtime type-checking, because static type information has been erased.

class ObliviousClass {

  private final Map<Key, Object> map = new HashMap<Key, Object>();

  public Object put(Key key, Object value)
  {
    return map.put(key, value);
  }

  public <T> T get(Key key, Class<? extends T> type)
  {
    return type.cast(map.get(key)); 
  }

}

Usage would look like this:

oc.put(k1, 42);
oc.put(k2, "Hello!");
...
Integer i = oc.get(k1, Integer.class);
String s = oc.get(k2, String.class);
Integer x = oc.get(k2, Integer.class); /* Throws ClassCastException */

---

Related Topics