Name: rmT116609			Date: 06/17/2003


A DESCRIPTION OF THE REQUEST :
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
logic.

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
bloat.


JUSTIFICATION :
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.



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