Java generics and design patterns: not parameterizing a reference to a generic type is always a bad thing?

Question

this question is partially related to my last question.

I have a generic class representing a collection of generic objects:

public interface MyObject<N extends Number>{}

public interface MyCollecion<N extends Number> {
    public foo(MyObject<N> obj)
}

In my design these collections of objects are constructed by a client class (let's call it CollectionBuilder) through an abstract class approach:

public interface AbstractCollectionFactory {
    public abstract <N extends Number> MyCollection<MyObject<N>> createCollection(String collectionType);

}

Generic collections should be constructed this way:

public class CollectionBuilder{
    AbstractCollectionFactory f;
    public void buildDoubleCollection(){

         MyCollection<MyObject<Double>> c = f.<Double>createCell("MyType");
    }
    public void buildIntegerCollection(){...}
}

Ok.Since here all ok. CollectionBuilder is aware of what is the generic concrete type to specify (Double in this case) and can build correctly. I can compile this with no warning and all should work fine.

Now I have a question related both to generics and the design of my program.

I have another class in my application that need to use the collection built by CollectionBuilder (let's call this class UserClass). The UserClass:

1. Doesn't need to know of which particular concrete type are its collection (MyCollection<MyObject<Double>> or MyCollection<MyObject<Integer>>).
2. perform some operations on these collections invoking some methods defined in MyCollection interface.
3. I would not want to add a generic type to it.

In the situation described, is that a bad idea do not parametrize the generic class MyCollection insied UserClass?

public UserClass{
     MyCollection a;  //warning 
     MyCollection<?> b; //no warning

     public method(MyObject o){  //warning
          a.foo(b); //compile       
     }
     public method2(MyObject<?> o){
          b.foo(o); //error do not compile
     }
}

Java compiler always protest with a warning if I don't specify the generic parameter. Anyway from inside UserClass I don't know the concrete parameter (and I would like to don't know it) and even declaring it with "?" don't allow me to call method foo on MyCollection.

So the question are:

1. not parameterizing a reference to a generic type is always a bad thing?
2. if answer at 1 is NO, is this a right situation for not doing it?
3. if answer at 1 is YES, how can I use MyCollection method from inside UserClass without knowing their generic types?
4. Is mine a bad design ?

I hope to have been clear. I've be struggling on this problem from days, and I have no idea. Please help me.

Answer 1

1. According to the Java compiler, yes. And this answer contains a lot of good points as to why. Personally I disagree in some situations, especially where the use of Class is concerned (like for instance, if you have a Map<Class, Object>). In such cases having to always tack <?> on to the end of "Class" just feels like needless tedium, and does not make the code any more readable.

   The idea of having Class be parameterized based upon what type of Object it is associated with has always felt a bit dubious in the first place, to me. The point of Class is to have a common interface that can be used to obtain information about any Object (ala reflection), regardless of its type.

   But I digress. According to the Java compiler and the implementors of generic types, you should always parameterize your reference, even if you are only using <?>.

2. Not applicable. Though you can always not declare any type information, and then use @SuppressWarnings("unchecked") along with an explicit cast to make the compiler happy.

3. See Bohemian's answer.

4. There's not really enough information to say. Though off the top of my head, I'm not sure what the actual use-case would be for having "a generic class representing a collection of generic objects". Why not just use the collections directly?

Answer 2

There's almost always a way to parameterise your code. In brief, I'd be typing UserClass, like this:

public UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }
} 

Edit
If you're worried about poluting your client code with generics, you can make an abstract typed class and provide non-typed implementations, like this:

public abstract UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }
} 

public class DoubleUserClass extends UserClass<Double> {}

To reduce class bloat, you can put the non-typed classes inside the base class:

public abstract UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }

     public static class DoubleImpl extends UserClass<Double> {}
     public static class FloatImpl extends UserClass<Float> {}
     public static class IntegerImpl extends UserClass<Integer> {}
} 

And use them like this: new UserClass.DoubleImpl() etc