Java Generics – Wildcard vs Type Parameter in Method Signatures

genericsjava

I'm having a hard time trying to figure out why the two methods declarations have different results.

On the first method signature its obvious you can't compare Apples with Apples and Oranges with Orange, because none of them implement Comparable<>.

But on the second method I was surprised that you could actually compare Apples with Apples and Oranges with Oranges.

I remember on a previous version of IntelliJ (14) a call to the second method with a List of Apples or Oranges was giving a compilation error. But the newer versions of IntelliJ don't report that problem anymore.

I would appreciate if someone could explain me what's the difference between the two methods signatures using the Fruit example.

class Fruit implements Comparable<Fruit> {}

class Apple extends Fruit {
}

class Orange extends Fruit {
}

static <T extends Comparable<T>> T maxSimple(Collection<T> coll) {
}

static <T extends Comparable<T>> T max(Collection<? extends T> coll) {
}

Best Answer

What are the constraints on T?

In your first example, T must equal the collection type and be comparable to exactly itself. Note that List<Apple> does not extend List<Fruit>, and if it did, you could add Oranges to the apple list.

Try T as Apple : Apple is not Comparable<Apple>, so this fails. Try T as Fruit : Collection<Fruit> is not a supertype of Collection<Apple>, so this fails

In your second example, you allow the collection type to range over the subtypes of T, so T can be Fruit and you have Collection< any fruit subtype >

There is a third option that you havent considered:

static <T extends Comparable<? super T> T max(Collection<T> coll)

Here we allow T to be bound to Apple, as Apple is comparable to one of its superclasses

Related Solutions

Java Generics – Balancing Expressiveness and Simplicity

Guava Collections already provides this functionality and if you can hold off a little longer, Java 8 will provide this also :-). FWIW I think your use of ? extends T is the correct idiom, not much you can do given that Java uses Type Erasure

Java – Refactoring two classes from third-party library that could have extended a base class

This is a refinement of @user2670177 answer:

If the function signatures of both are nearly the same it might be easier to use inheritance instead of composition.

Given you have Oranges and Appels you want to process

class Orange {
    public void setColor(Color color){}
    public void setPrice(int euroCents){}
    public void setCount(int numberOfItems){}
}

class Apple {
    public void setColor(Color color){}
    public void setPrice(int euroCents){}
    public void setCount(int numberOfItems){}
}

You can define a common interface for both

interface MyFruitInterface{
    void setColor(Color color);
    void setPrice(int euroCents);
    void setCount(int numberOfItems);
}

and attach the interface to the inherited class

class MyOrangeImpl extends Orange implements MyFruitInterface {
} 

class MyAppleImpl extends Apple implements MyFruitInterface {
}

Now your common code MQObject can handle both:

class MQObject {
    private MyFruitInterface fruit;
    MQObject(MyFruitInterface fruit) {
        this.fruit = fruit;
    }

    void setPriceColorCount(int euroCents, Color color, int numberOfItems) {
        fruit.setPrice(euroCents);
        fruit.setColor(color);
        fruit.setCount(numberOfItems);
    }
}

void testMQ() {
    MQObject applMQObject = new MQObject(new MyAppleImpl());
    MQObject orangeMQObject = new MQObject(new MyOrangeImpl());
}

Best Answer

Related Solutions

Java Generics – Balancing Expressiveness and Simplicity

Java – Refactoring two classes from third-party library that could have extended a base class

Related Topic