Why does Java not support type inference for constructors?

Question

E.G. to create an ArrayList of Strings we have to do something like

List<String> list = new ArrayList<String>();

whereas it should be able to infer the parameter type for the constructor so that we only have to type

List<String> list = new ArrayList();

Why can't the type be infered in the same way that type parameters are infered for generic methods.

Answer 1

It can be and it's a feature slated for inclusion in JDK7.

Answer 2

This is a Java 7 improvement. The syntax will be:

List<String> strings = new ArrayList<>();

The official proposal, accepted for inclusion in Project Coin is Improved Type Inference for Generic Instance Creation

According to Rémi Forax, the change is already in the mercurial repository.

Answer 3

The type can be inferred, but the authors just decided it is better not to have type inference at all then have some limited type inference in some cases.

If you want type inference on jvm, check out scala.

Answer 4

As others have said, this is on the list for Java 7. However, I'd like to point out that the Google Collections Library already sort of supports this for various collections, if you're happy to use static imports. For instance, I frequently write code such as:

List<String> list = newArrayList();

All you need is the static import and remove the space between new and ArrayList() :)

(The static import would be to the Lists class, btw. There are similar methods for maps etc.)

Answer 5

Aside from JDK7 features, I'm guessing so you can use extends and super.

class Animal {}
class  Dog extends Animal {}

List<? extends Animal> anims = new ArrayList<Dog>();
List<? super Dog> superdogs = new ArrayList<Animal>();

You wouldn't be able to infer in these two cases.

Answer 6

You want a reason the current Java doesn't support it.

I can only say that Java typically takes little steps wherever possible. I would guess that there was some little technical glitch that they weren't sure about getting "Right" before Java 7--probably something to do with being absolutely certain it wouldn't create an ambiguous case in some older or non-generic code.

Notice how Robert pointed out that the syntax will be this:

List<String> strings = new ArrayList<>();

Notice the empty <>? I'm guessing that's to disambiguate this type of inference from older non-generic code; it's probably just something they didn't think of at first.

Answer 7

I'm no Java super-expert, so I'm not completely sure about what I will state. Here are my thoughts:

As Java implements generics by erasure, for every generic type there is an underlying raw type. If you define a generic type, there will be an underlying raw type that will use Object all around.

When you instantiate a new ArrayList, it would be wrong for compiler to infer the type parameter from the instantiation class (ArrayList<String> in your example), as there is a class with that exact name and no type parameter (that is the raw type, ArrayList). I also guess that this is why in java 7 you will have to add <> to the constructor call to tell the compiler to infer the type.

One could argue that the compiler should instantiate the raw type only when the definition class is the raw type, but I think that it would be confusing. I think that the compiler have to infer from incomplete expressions that would be invalid with no given context, which is not the case for the new ArrayList() statement.

I hope this is clear, and that if I'm wrong someone can correct me.

---

Side note:

Also, beware that the raw class is not the same as the type using Object as type parameter:

List<String> list = new ArrayList();

is valid, where as

List<String> list = new ArrayList<Object>();

is not. In the first case, the raw type can be used as if it was a generic type, but in the second case you ask for contravariance which is not available (not if you don't use wildcards).