How to iterate over a wildcard generic?

How can I iterate over a wildcard generic? Basically I would like to inline the following method:

private <T extends Fact> void iterateFacts(FactManager<T> f开发者_JAVA技巧actManager) {
    for (T fact : factManager) {
        factManager.doSomething(fact);
    }
}

If this code is in a separate method as shown, it works because the generic method context allows to define a wildcard type (here T) over which one can iterate. If one tries to inline this method, the method context is gone and one cannot iterate over a wildcard type anymore. Even doing this automatically in Eclipse fails with the following (uncompilable) code:

...
for (FactManager<?> factManager : factManagers) {
    ...
    for ( fact : factManager) {
        factManager.doSomething(fact);
    }
    ...
}
...

My question is simply: Is there a way to put some wildcard type one can iterate over, or is this a limitation of generics (meaning it is impossible to do so)?

No. In situation like this, the workaround is to create a helper method.

The JLS has this example http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.10

public static void reverse(List<?> list) { rev(list);}
private static <T> void rev(List<T> list) { ... }

The issue is, we have a List<?> object. We know it must be a List<X> of some X, and we'd like to write code using X. Internally compiler does convert the wildcard to a type variable X, but Java language does not offer programmers a direct way to access it. But if there's a method accepting List<T>, we can pass the object to the method. Compiler infers that T=X and the call is good.

If there's no type erasure, X can be known at runtime, then Java would definitely give us a way to access X. However as of today since X isn't available at runtime, there's not much point. A purely synthetic way could be provided, which is unlikely to be simpler than the helper method workaround.

Type parameters can only defined on

• types (i.e. classes/interfaces),
• methods, and
• constructors.

You would need a type parameter for a local block, which is not possible.

Yeah, I missed something like this sometimes, too.

But there is not really a problem with having the method non-inlined here - if it presents a performance bottleneck where inlining would help, Hotspot will inline it again (not caring about the type).

Additionally, having a separate method allows giving it a descriptive name.

Just an idea, if you need this often:

interface DoWithFM {
   void <T> run(FactManager<T> t);
}

...
for (FactManager<?> factManager : factManagers) {
    ...
    new DoWithFM() { public <T> run(FactManager<T> factManager) {
        for (T fact : factManager) {
            factManager.doSomething(fact);
        }
    }.run(factManager);
    ...
}
...

You can always fall back to Object

for (FactManager<?> factManager : factManagers) {
    ...
    for ( Object fact : factManager) {
        factManager.doSomething(fact);
    }
    ...
}

This, of course, is subject to what is the actual declaration of doSomething.

If doSomething is declared as this void doSomething( T fact ), then your recourse here would be to use a raw type and swallow unchecked warnings. If you can guarantee that FactManager can only have homogeneous Facts inserted, then that may be an OK solution.

for (FactManager factManager : factManagers) { // unchecked warning on this line
    ...
    for ( Object fact : factManager) {
        factManager.doSomething(fact);
    }
    ...
}

Well, I can think of a way to do it using inner classes, because the inner class shares the type parameter with its enclosing type. Also, even using wildcards you could still process your collections thanks to wildcard capture conversion.

Let me create an example. This code compiles and runs fine. But I cannot be certain if the use of inner classes would be an issue for you.

//as you can see type parameter belongs to the enclosing class
public class FactManager<T> implements Iterable<FactManager<T>.Fact> {

    private Collection<Fact> items = new ArrayList<Fact>();

    public void doSomething(Fact fact) {
        System.out.println(fact.getValue());
    }

    public void addFact(T value) {
        this.items.add(new Fact(value));
    }

    @Override
    public Iterator<Fact> iterator() {
        return items.iterator();
    }


    public class Fact {
        //inner class share its enclosing class type parameter
        private T value;

        public Fact(T value) {
            this.value = value;
        }

        public T getValue() {
            return this.value;
        }

        public void setValue(T value) {
            this.value = value;
        }
    }

    public static void main(String[] args) {
        List<FactManager<String>> factManagers = new ArrayList<FactManager<String>>();

        factManagers.add(new FactManager<String>());
        factManagers.get(0).addFact("Obi-wan");
        factManagers.get(0).addFact("Skywalker");

        for(FactManager<? extends CharSequence> factManager : factManagers){
            //process thanks to wildcard capture conversion
            procesFactManager(factManager);
        }
    }

    //Wildcard capture conversion can be used to process wildcard-based collections
    public static <T> void procesFactManager(FactManager<T> factManager){
        for(FactManager<T>.Fact fact : factManager){
            factManager.doSomething(fact);
        }
    }
}

This is more precisely matched to the method you defined (that is, if you can call iterateFacts() with the FactManagers in factManagers, you know that the FactManager contain items that are some subclass of Fact).

for (FactManager<? extends Fact> factManager : factManagers) {
    for (Fact fact : factManager) {
          factManager.doSomething(fact);
    }
}

I would tend to think, however, that you would declare FactManager to be generic for subtypes of Fact (just given the name of the class), e.g.

class FactManager<T extends Fact> implements Iterable<T> {
     ...
}

The Eclipse refactoring fails because it cannot infer the type of an object contained by FactManager<?>.