Java Iterable Vs Iterator

In my experience, the most important consideration is whether the item in question should be able to be traversed more than once. This is because you can always rewind an Iterable by calling iterator() again, but there is no way to rewind an Iterator.

Iterator is single traversal.
 
In Java 5

Iterable<SomeObj> objs = new Iterable>() {
    public Iterator<SomeObj> iterator() {
        return object.getChildren();
    }
}; 

In Java 8, working with legacy Iterator-based interfaces is a little easier, thanks to method references. The Service.getPorts example above could be written as:

Iterable<SomeObj> objs = object::getChildren;

And you can even inline it directly into the for loop:

for (SomeObj objs : object::getChildren) {
    // ...
} 

A Collection is an Iterable... So you can write:

public static void main(String args[]) {
    List<String> list = new ArrayList<String>();
    list.add("a string");

    Iterable<String> iterable = list;
    for (String s : iterable) {
        System.out.println(s);
    }
}

Java Generic < ? > vs < T >

Using "?" is the same as "any", whereas "T" means "a specific type". So, compare these interfaces:

public interface StrictClass {
 public T doFunction(Class class);
}


public interface EasyClass {
 public < ? >  doFunction(Class class);
}


When to use which one

There are also use cases for choosing over (or vice versa) that apply when you don't add type parameter to the class that encloses the method. For example, consider the difference between

public boolean add(List j) {
    boolean t = true;
    for (JLabel b : j) {
        if (b instanceof JLabel) {
            t = t && labels.add(b);
        }
    }
    return t;
}
and

public boolean add(List j) {
    boolean t = true;
    for (JLabel b : j) {
        if (b instanceof JLabel) {
            t = t && labels.add(b);
        }
    }
    return t;
}
The first method will actually not compile UNLESS you add an appropriate type parameter to the enclosing class, whereas the second method WILL compile regardless of whether the enclosing class has a type parameter

Using Type Tokens to Retrieve Generic Parameters

Interesting read

http://www.jquantlib.org/index.php/Using_TypeTokens_to_retrieve_generic_parameters

Type Erasure : Why the information is dropped at compile time

We all know that, at compile-time, the compiler has full type information available but this information is intentionally dropped in general when the binary code is generated, in a process known as type erasure. 

So to put in different words this feature is offered by javac :)

one needs to realize the concept of type erasure derives from a need of compatibility with previous versions of java.

• Source compatibility (Nice to have...)
• Binary compatibility (Must have!)
• Migration compatibility
  
  • Existing programs must continue to work
  • Existing libraries must be able to use generic types
  • Must have!

This is done this way due to compatibility issues... The intention of language designers was providing full source code compatibility and full binary code compatibility between versions of the platform. If it was implemented differently, you would have to recompile your legacy applications when you migrate to newer versions of the platform. The way it was done, all method signatures are preserved (source code compatibility) and you don't need to recompile anything (binary compatibility).

google collections library

Link is more than enough :)
http://code.google.com/p/google-collections/