Java generic programming with unknown generic type of interface
Asked Answered
R

1

2

I'm using several interfaces with generics types. While combining it together I have some problems when I have to use them from a part of the code that is unaware of the concrete type of the generic parameter.

Suppose I have the following interface:

public interface MyObjectInterface<T extends Number> {}

The object implementing that interfaceare stored in a generic collection with the same generic type:

public interface MyCollectioninterface<T extends Number> {
    public void updateObject(MyObjectInterface<T> o);
}

Concrete instances of MyCollectionInterface hold several MyObjectInterface of the same generic parameter:

public class ConcreteCollection<T extends Number> implements
 MyCollectionInterface<T> {
    List<MyObjectInterface<T>> list;
    public void updateObject(MyObjectInterface<T> o){}

}

Now, I have several questions on how to use these generic interfaces from a client class that is (and must be) unaware of the concrete type of generics.

Suppose I have the following class:

public class ClientClass{

    private MyCollectionInterface<?> collection;  //1st possibility
    private MyCollectionInterface collection;  //2nd possibility

    public ClientClass(MyCollectionInterface<?> collection){
        this.collection = collection;
    }

    public void foo(MyObjectInterface<?> o){
         this.collection.updateObject(o);  //this doesn't compile
    }
    public void foo(MyObjectInterface<? extends Number> o){
         this.collection.updateObject(o);  //this doesn't compile either
    }
    public void bar(MyObjectInterface o){
         MyObject b = o; //warning
         this.collection.updateObject(o);  //this compile but with warnings
    }
}

First Question :

  1. Considered the fact that ClientClass doesn't care of which concrete type extending Number is the collection, should I declare collection with or without "?" ? If I use the second version I get the following warning:

MyCollectionInterface is a raw type. References to generic type LatticeInterface should be parameterized

Second Question :

  1. Why method foo doesn't compile?

Third question:

  1. It seems that I need to use bar signature to call updateObject method. Anyway this solution produce a warning while trying to assign the MyObjectInterface parameter, like in the first question. Can I remove this warning?

Last questions:

  1. Am I doing something weird with this generic interfaces and I should refactor my code?
  2. Do I really have to care about all these warnings?
  3. How can I use safety a generic interface from a class where I don't know its concrete type?
Reinaldoreinaldos answered 4/9, 2011 at 15:17 Comment(2)
Shouldn't it be MyObjectInterface instead of MyObject in methods foo and bar?Uncanny
yes, my fault. I fixed it. It's MyObjectInterface.Reinaldoreinaldos
U
1

Ok, I played a bit with your code and reached a conclusion.

The problem is that your ConcreteCollection (and its interface MyCollectionInterface) declare the method updateObject as receiving an argument of type MyObjectInterface<T> (where T extends Number) - note that the type is a concrete one (not a wildcard).

Now, in your client class you are receiving a collection and storing it as MyCollectionInterface<?> but the instance that is passed to ClientClass' constructor will be of a concrete type, for instance:

new ClientClass(new ConcreteCollection<Integer>());

This means that the method updateObject of that instance would only accept an argument of type MyCollectionInterface<Integer>.

Then, in method foo you are trying to pass a MyObjectInterface<?> to updateObject, but since the compiler doesn't know which generic type your collection accepts (it could be Integer like in my example but it could also be Double or any other type that extends Number), it won't allow any object to be passed.

Long story short, if you declare your reference as MyCollectionInterface<?> you won't be able to call updateObject on it. So you have two choices:

1) Pick a concrete type and stick with it:

private MyCollectionInterface<Number> collection;

public ClientClass(MyCollectionInterface<Number> collection){
    this.collection = collection;
}

public void foo(MyObjectInterface<Number> o){
     this.collection.updateObject(o);  //compiles
}

But then you are limiting the collections you can receive in your constructor (which may not be a bad idea), or:

2) Modify your interface to accept a wildcard type:

public interface MyCollectionInterface<T extends Number> {
    public void updateObject(MyObjectInterface<? extends Number> o);
}

public class ConcreteCollection<T extends Number> implements MyCollectionInterface<T> {
    List<MyObjectInterface<T>> list;
    public void updateObject(MyObjectInterface<? extends Number> o) {}
}

private MyCollectionInterface<?> collection;

public ClientClass(MyCollectionInterface<?> collection){
    this.collection = collection;
}

public void foo(MyObjectInterface<?> o){
     this.collection.updateObject(o);  //compiles
}

Also, note that even in 2) you could still run into the same problem in your implementation of the updateObject method unless you declare your list something like this (with ArrayList for example):

List<MyObjectInterface<? extends Number>> list = new ArrayList<MyObjectInterface<? extends Number>>();

In which case you could as well remove the <T extends Number> from MyCollectionInterface and ConcreteCollection since T isn't used anymore.

@Your last questions:

1) Probably yes
2) You should
3) You can't, if you don't really care which objects you store in the collection, you should ditch generics altogether.

Sorry for the long answer, hope this helps.

Uncanny answered 4/9, 2011 at 16:27 Comment(1)
The problem isn't the method foo. Even if I change it signature the problem is here : public void updateObject(MyObjectInterface<T> o){} . Even if T is declared as T extends Number, the line : this.collection.updateObject(o); doesn't work. I can declare o even <? extends Number> and it won't work either.Reinaldoreinaldos

© 2022 - 2024 — McMap. All rights reserved.