Why can't you create an instance of a generic type using "new" operator?

Short answer: Java is a compiled programming language, which means that your bytecode is constant at runtime. It is impossible to generate bytecode for new E() if E is unknown.

Explanation: Generic information is erased in runtime:

public class Container<E> {
     private E item;
     public E getItem() {return item;}
}
class BoxWithPresent extends Container<Present> {
}
class SimpleBox extends Container {
}

In bytecode class BoxWithPresent contains field item of type Present, but class SimpleBox contains field item of type Object (because type E was not specified).

Now you write abstract instantiation method:

public class Container<E> {
    public <E> E createE() {
        return new E(); // imagine if that was allowed
    }
}

What bytecode should be generated here? .class file is generated right now, at compilation time, but we have no idea what is E type.

So.. can new T() be replaced with new Object()? Bad idea, class BoxWithPresent won't like it, because it expects that E is Present.

Can it be replaced with class.newInstance()? Again no, there is no class variable in method scope.

That's why new E() is impossible.
But there are workarounds with passing class as parameter, or extracting generic information.

The shortest answer is that generic type parameters do not exist at runtime.

Generics were retrofitted into the Java language in release 5. In order to maintain backward compatibility with the existing code base, they were implemented by erasure.

Generic type parameters exist in your source code at compile-time, but nearly all evidence of them is removed in the byte code during compilation. This implementation of generics was chosen because it maintained inter-operability between pre-generics code and Java 5+ generic code. Type safety with generics is largely, therefore, a compile-time only phenomenon. If your generic code compiles without error and without warnings, then you are assured that your code is type safe.

Because of erasure, however, there are (as of Java 5) two kinds of types:

• Reifiable. For example String, Integer, etc. A reifiable type has the same type information at compile-time as it has at run-time.

• Non-reifiable. For example List<String>, List<T>, and T. Non-reifiable types have less type information at run-time that at compile time. In fact, the run-time types of the above are List, List, and Object. During compilation, the generic type information is erased.

You cannot use the new operator with non-reifiable types because there is no type safe way at run-time for the JVM to generate an object of the correct type.

Source code:

T myObject = new T();

The above does not compile. At run-time, T has been erased.

A strategy for circumventing some problems with type erasure and Java generics is to use type tokens. This strategy is implemented in the following generic method that creates a new T object:

public <T> T newInstance(Class<T> cls) {
    T myObject = cls.newInstance();
    return myObject;
}

The generic method captures the type information from the Class object that is passed as a parameter. This parameter is called a type token. Unfortunately, type tokens themselves must always be reifiable (because you can't get a Class object for a non-reifiable type) which can limit their usefulness.