United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6220689 Type arguments for a class shall be inferred on constructor invocation
JDK-6220689 : Type arguments for a class shall be inferred on constructor invocation

Details
Type:
Enhancement
Submit Date:
2005-01-24
Status:
Closed
Updated Date:
2010-04-04
Project Name:
JDK
Resolved Date:
2006-12-08
Component:
specification
OS:
solaris_9
Sub-Component:
language
CPU:
sparc
Priority:
P4
Resolution:
Not an Issue
Affected Versions:
5.0
Fixed Versions:

Related Reports
Relates:
Relates:
Relates:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :
Consider the following piece of code:

List<Map<String,List<Integer>>> list = new ArrayList<Map<String,List<Integer>>>();

One has to repeat type parameters twice (and they can be even longer
than in this example). This kind of repetition of type arguments is
bug-prone and creates unnecessary clutter in the code. One shall be
able to write this code simpler, like this:

List<Map<String,List<Integer>>> list = new ArrayList();


JUSTIFICATION :
For ease of development.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The proposed code shall compile normally via type parameter inference mechanism.

ACTUAL -
This code complies, but produces unchecked warnings.


---------- BEGIN SOURCE ----------
import java.util.*;

public class ListCreate {
	public static void main(String[] args) {
		List<Map<String,List<Integer>>> list = new ArrayList();
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use static factory methods instead of constructors. They work just
fine with type argument inference without any warnings.

import java.util.*;

public class ListCreate2 {
        public static void main(String[] args) {
                List<Map<String,List<Integer>>> list = newArrayList();
        }

        public static <T> ArrayList<T> newArrayList() {
                return new ArrayList<T>();
        }
}
###@###.### 2005-1-24 13:16:39 GMT

                                    

Comments
EVALUATION

Inference of actual type arguments of generic types is not going to happen.
See bug 6242254 for discussion. What might help in this case is type aliasing,
which would likely be done through extending import clauses.

There are separate bugs for that as well.
###@###.### 2005-04-26 18:26:24 GMT
                                     
2005-04-26
EVALUATION

If the designer of a class can control when inference is
used, perhaps it would be less problematic.

We could enhance generic constructors so that the type
variable can be used to specify the type of the new
instance, for example:

class Foo<T> {
    <S> Foo<S>() {}
}

The second <S> is the "enhancement".

See http://forum.java.sun.com/thread.jspa?threadID=668411
                                     
2005-10-26
EVALUATION

A nominal system where aliases are declared explicitly (and can even be suggested by your IDE) is much better for readability than an inference system. When inference cannot unify explicit type arguments on the LHS with implicit type parameters on the RHS, the errors alone will be incomprehensible. (This is alluded to in the 6242254 Evaluation.)

Moreover, if you allow
  List<Map<String,List<Integer>>> list = new ArrayList();  // (1)
then you have to allow
  List<Map<String,List<Integer>>> list = m();  // (2)
  ArrayList m() { return new ArrayList(); }
or even
  void n(List<Map<String,List<Integer>>> x) {...}
  n(m());  // (3)

It's one thing to do inference at a 'new' statement like (1), but to do it at arbitrary method calls like (2) and (3) would imply target typing everywhere. This is definitely not going to happen.
                                     
2006-12-08



Hardware and Software, Engineered to Work Together