JDK-4879776 : Constructor type inference (JSR14 + JSR65 ++)
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 5.0,7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-06-17
  • Updated: 2011-10-31
  • Resolved: 2011-10-31
Related Reports
Duplicate :  
Duplicate :  

Name: rmT116609			Date: 06/17/2003

Type inference concept (for details see JSR14 draft) shall be used for
more good, even beyond generic types. The lack of any type inference
in the original Java language crippled the language in may ways (even
without any relation to generic types). For example, it is strange
(for a high level language, at least) to learn that the following code
works perfectly:

int[] a = { 1, 2, 3 };

while the following code does not:

int[] a;
a = { 1, 2, 3 };

Likewise, Arrays.asList({"a", "b", "c"}) does not work.

It is a perfect time for JSR14 team to join effort with JSR65 (Concise
Object-Array Literals) team. I understand, that this could not be
easily done in the original Java (due to a complete lack of the
concept of type inference), but in the new Java [with type inference]
it's just a cake.

Moreover, due to lack of type inference, original Java code has been
always riddled with idioms like:

MyContainer mc = new MyContainer();

Here one must needlessly specify "MyContainer" name twice. Of course,
modern IDEs help to alleviate this problem somewhat by using "smart
typing" features to repeat the type after "new" keyword by a simple
key combination. But I'd rather call this "dumb typing" feature,
because this kind of dumb work compiler should have been doing in the
first place, while the programmer shall concentrate on the program's

I believe, that Tiger release is concerned with "ease of use"
paradigm, so that's a perfect time to bring constructor type inference
on the table. If not addressed properly, it will only worsen with the
introduction of generics. Consider programmer's problems to write and read the code like:

MyContainer<EventHandler<GUIEvent>> mc =
    new MyContainer<EventHandler<GUIEvent>>();

(it does not even fit on the 70 char line of my message anymore!)

But wait - we finally have type inference concept in the Java language
(as a part of JSR14) and suddenly the means to address this problem do
not seem out-of-place. Concrete syntax may vary. Choose one of:

MyContainer<EventHandler<GUIEvent>> mc = new ();
MyContainer<EventHandler<GUIEvent>> mc = ();
MyContainer<EventHandler<GUIEvent>> mc = {};

or something else. But this must be addressed. Otherwise, generics are
going to bring a lot of harm to the language and code clarity, because
of the promotion and further proliferation of the aforementioned code

This shall bring more ease to Java language coding by reducing the need to repeat type names where they are obvious from the context (that is currently somewhat alleviated by modern IDEs). Resulting reduction in code size shall also make it easier to review.

Use of IDEs with "smart code completion" somewhat helps.
(Review ID: 188134) 

EVALUATION Unfortunately, JSR65 has been shut down. Certainly, there was a synergy between it and type inference and autoboxing; this was by design. Popular taste favored variable arity methods instead. For once, I've relented. You can now save yourself typing two curly braces on occasion, in exchange for a less general construct. As for type inference and target typing: these things are superficially attractive, but can cause a lot of trouble. Ease of use is not about saving lazy coders a few keystrokes; IDEs can do that. The same applies to lines of more than 70 characters; we don't use punched cards anymore. Programs are read orders of magnitude more times than they are written (except for trivial programs and student exercises). Explicit types provide readability and valuable redundancy (which catches errors). ###@###.### 2003-08-22