Q:

How does parameterization work in Collections.EmptyList class?

I just wonder what happens after I execute:
List list = Collections.<String>emptyList();
Here is Collections code:
public static final List EMPTY_LIST = new Collections.EmptyList(null);
public static final <T> List<T> emptyList() {
        return EMPTY_LIST;
    }

private static class EmptyList<E> extends AbstractList<E> 
                                  implements RandomAccess, Serializable {

    private EmptyList() {
    }

    //...
}

How is it possible to call EmptyList(null) while EmptyList doesn't have constructor with arguments. 
Please, explain me the process how does Collection's method generic type T becomes EmptyList's generic type E? 

A:

I just wonder what happens after I execute

Nothing happens because everything about Generics and type parameters goes on at compile time.

How is it possible to call EmptyList(null) while EmptyList doesn't have constructor with arguments

It is not possible, but no JDK code I saw creates the empty list by passing null to the constructor. Don't trust decompiler code.

explain me the process how does Collection's method generic type T becomes EmptyList's generic type E?

T is a type variable capturing the type inferred at each call site of emptyList(). This variable is "passed" (during static type analysis) to emptyList so that the type of the returned value is List<T>. E is the name of the type parameter of EmptyList and this type parameter assumes the value of T in that particular type instantiation. This is very similar to how an ArrayList<E>'s E becomes String when you say new ArrayList<String>().

A:

In addition to @MarkoTopolnik answer I can explain why decompiler shows that null is passed into constructor parameters.
When you create private class with no explicit constructor, its default no-arg constructor is generated inside the bytecode as private:
private static class EmptyList<E> {
    private EmptyList() {
    }
    ...
}

This way the class cannot be instantiated from other classes (JVM will not permit this). But it does instantiated in Collections class:
public static final List EMPTY_LIST = new EmptyList<>();

From the JVM point of view there's no thing like "nested class". The EmptyList class is just another class (named Collections$EmptyList) in the same package. If javac compiler generate the direct call to the private constructor, then JVM will just throw an exception during the Collections class initialization. To fix this problem javac compiler introduces one more additional constructor with package-private access:
private static class EmptyList<E> {
    private EmptyList() {
    }

    EmptyList(Collections$1 ignore) {
        this();
    }
    ...
}

This artificial constructor has one parameter just to distinguish from the existing constructor. Also to avoid possible arguments clash an additional artificial class Collections$1 is generated! The purpose of this class is just to be the parameter of such artificial constructors. It's never instantiated and even initialized.
So finally you can instantiate the EmptyList from another class (within java.util package) calling this new constructor:
public static final List EMPTY_LIST = new EmptyList<>((Collections$1)null);

This is how it looks in the bytecode. Seems that decompiler is not smart enough to detect this situation and remove the artificial constructor parameter in the output (actually it should be quite simple).

