Java genericity - Inference and instanciation

[Fabien Dupuit]

Hello, i have a question regarding genericity. I don't understand why the compiler can use inference to give a type. But it doesn't work for instanciation.

class A<T> {
  T a;
   
  void f() {
    a = new T();
  }
}

A<String> a = new A<>();

With inference, i'm not obligated to complet the '<>' from the instanciation of 'a'. From the context, it will find out that <T> parameter from the class is a String so 'a' is therefor a String.
But why can't it do the code below if he know that 'T' is of String type ?

a = new String();

Thanks

[Paul Clapham]

I don't know what you mean when you say "doesn't work" there. Perhaps you could explain a bit?

Anyway if you have a suitably recent version of Java you can use

var a = new String();

which works perfectly well, although it isn't related to generics.

[Mike Simmons]

Fabien Dupuit wrote:From the context, it will find out that <T> parameter from the class is a String so 'a' is therefor a String.

That context is outside the class, in your example.  How far away should the compiler look for context like this?  Like, in the same file, in the same package, in the same project, on the same computer, in the whole organization you're sharing your computer with?  What if there's code somewhere that uses T as a String, and somewhere else there's code that uses T as an Integer?  Or a StringBuffer?  How can the compiler know, within the class A, what other code is going to use it for?

In general, we want to be able to compile a class based on declarations in that class, not by having to scan code outside the class.  Of course when we use another specific class within our class, that other class needs to be compiled before our class.  But with generics like T, there's no other class to go and compile first.  Instead, your class A needs to have all the info it needs to be compiled, within the definition of T.  Code lying around elsewhere is not relevant for compiling class A. Within the class A, the generic parameter T could be anything, since it's just declared there as <T>, with no other restrictions (no super or extends).

Furthermore, the compiler is never going to let you create an instance using "new" without specifying exactly what the class is.  That's how the rules work.  You can't just say "create some sort of T" and let the computer surprise you - T could mean many things.  And with generics, they are generally used in places you need to be flexible, where more than one type is possible.  So the rule is, you can't create a new something with a generic type.  That is, you can create something like new ArrayList<T> (which is fundamentally an ArrayList), but not a new T.

[Campbell Ritchie]

To continue from what Mike said, what did the compiler error say? You need to give the name of a class, which T isn't.
To look at it another way, whichever way you write the argument to the compiler, can the compiler ensure that the constructor will have those parameters? You cannot know that you want a String there. How would you compile it if you later wrote this?A<Integer> a = new A<>();Generics allows for all possibilities.
Besides, it is probably not good programming to use the copy constructor for a String, nor that no‑arguments constructor.

[Rob Spoor]

What if I did the following?

A<LocalDate> a = new A<>();

What would a.f() do, considering that LocalDate doesn't have a no-arg constructor?

But even if you could find a way to declare that a constructor exists (and I actually have devised syntax for this), it's not possible because of type erasure. Generics in Java only exist at compile time. In the compiled byte code it's replaced by the best matching type:

With <T> the best matching type is Object

With <T extends X> the best matching type is X (for example, <T extends Serializable> leads to Serializable)

With <T extends X & Y> the best matching type is X as well. This is why Collections.max uses <T extends Object & Comparable<? super T>> and not <T extends Comparable<? super T>>; the former results in Object which was needed for binary compatibility, the latter results in Comparable

With <T super X> and <T super X & Y> the best matching type is Object

So your example would compile to this:

class A {
  Object a;
    
  void f() {
    a = new Object();
  }
}
 
A a = new A();

If I would try to access a.a, the compiler turns that into (String) a.a. Because it wouldn't be a String you'd get a ClassCastException.

[Rob Spoor]

Note that functional programming allows us to store the constructor as a field and provide it during construction of instances:

class A<T> {
    private final Supplier<T> aFactory;
    T a;

    public A(Supplier<? extends T> aFactory) {
        this.aFactory = Objects.requireNotNull(aFactory);
    }
    
    void f() {
        a = aFactory.get();
    }
}
 
A<String> a = new A<>(String::new);
// A<String> a = new A<>(() -> new String());