Yep, definitely difficult, and certainly not type-safe.  What would be
possible, though, is:

   T obj = T.class.newInstance();

or the equivalent with Constructor.  Currently, you need to pass an
actual parameter of type Class<T> somewhere.  Of course, since there is
only one possible value of that parameter, it's really no parameter at
all, but just syntax boilerplate... and worse: it exposes the use of
reflection on T as part of the public API of the element.

This was one of the two problems I mentioned earlier.

That is nothing to do with type erasure.

C++ templates manages it by being, if you like, a "syntax level" feature
rather than Java's "type level" feature.

The obvious way to solve the problem with Java is to introduce an
abstract factory:

interface MyFactory<PRODUCT> {
    PRODUCT newInstance(...);
}

More work for the trivial case, but more flexible and it clearly
expresses the type requirements within the type system.

Tom Hawtin

Ah!  That is one way of doing it.  Earlier, I proposed a different
solution.  That was to define the raw type as being the same as what is
now called the type erasure of the type, but expanded as an explicit
parameterized type instantiation.  For example, "Map" would become
"Map<Object,Object>".

This means, of course, that many of the existing uses of raw types would
be incompatible with generic types.  For example, a method defined to
take a parameter of Map would be incompatible with Map<String,String>
because there is no implicit assignment from Map<String,String> to
Map<Object,Object> (which is the implicit expansion of Map).  That's no
insurmountable problem, though... just an inconvenient API.  It can be
solved in several ways:

1. As always, deprecate the old API, introduce a new overload that takes
the right type (note that since we don't have type erasure, overloads
can be distinguished by type parameters).  Eventually, in Java 1.97
(also known as Java 97.0) remove the deprecated method.

2. In the short term, provide mappings that let someone define checked
adapters between types.  For example, define Collections.typedMap, which
is a method of two type parameters K and V, which takes a parameter of
type Map<Object,Object>, and returns a result of type Map<K,V>, and
performs type checking on every mutation operation to ensure that the
type safety is maintained.  Similar, define a Collections.untypedMap
which does the inverse (and also needs to type-check, since you can add
things to a Map<Object,Object> that can't be added to a Map<K,V>).