A DESCRIPTION OF THE REQUEST :

The verbosity of Java is often cited as a weakness of the language by programmers who are used to weakly-typed scripting languages. For instance, currently, in Java, it is possible to declare types with very long names, both due to the allowed length of identifiers and the existence of generic type parameters. The following might be the declaration of a variable:

Collection<Map<Map<Integer, String>,Map<Long,VeryLongTypeName>>> foo;

If the original long type declaration only existed once in the code, the problem would not be so bad. However, the design of the Java language forces this entire long type name to be restated verbatim every time the type itself or any type related to it is mentioned. For instance, if one were to try to iterate over the members of the above type, one would have to write:

Iterator<Map<Map<Integer, String>,Map<Long,VeryLongTypeName>>> iter = foo.iterator();

or:

for ( Map<Map<Integer, String>,Map<Long,VeryLongTypeName>> element : foo )
   doSomethingWith(element);

This problem is compounded by the lack, in Java, of an equivalent to the C++ 'typedef' keyword which would allow the above mega-declaration to be broken into smaller pieces. If Java had such a feature, we could write:

typedef Map<Integer,String> IntStringMap;
typedef Map<Long,VeryLongTypeName> VLTNMap;
typedef Map<IntStringMap, VLTNMap> MapMap;
Collection<MapMap> foo;


JUSTIFICATION :
Repeated long type declarations in Java programs make the code less readable, and make it difficult to modify (because in order to change a type, every instance of the type declaration must be found and modified individually).

Java programs that use generic types extensively would benefit tremendously by:
1) Having the Java language provide a way to create shorter aliases for type names, as per the C++ 'typedef' keyword.
2) Providing a way to implicitly determine the type for a variable based on the expression that is used to initialize it, as per the proposed new use of the C++ "auto" keyword. (see below)


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The C++ language has the above problems as well, and they tend to manifest even more often due to the design of the C++ Standard Template Library. After many complants from users, various members of the standards group have proposed a solution to this problem.

I think that their proposed solution would be valuable in Java also, and I would like to see it adopted. Specifically, if their solution were to be added to Java, the above code would be reduced to:

auto iter = foo.iterator();

for ( auto element : foo)
    doSomethingWith( element );

which is much more easily readable (and maintainable) than the current Java approach. The following would also be allowed:

auto i = 5 + 3;  // same as "int i = 5 + 3"
auto i = 5 + 3L;  // same as "long i = 5 + 3L"
for ( auto entry : (new HashMap<Integer, String>>).entrySet() ) { }
// 'entry' is of type HashMap.Entry<Integer,String>

Note that the above is still strongly-typed code. The type of each variable is simply determined by analyzing the compile-time-type of the value that it is initialized with. After that, the variable is treated like any other variable.

In summary, I would like to request that the 'auto' keyword be added to Java, defined in the manner used above (see the reference below for details). I would also like to request that the 'typedef' keyword be defined, for shortening use of long generic type declarations. Both of these could make Java programs considerably more concise and easy to read, as well as making them more maintainable.

More information on the new use of the 'auto' keyword for C++ can be found at:

Jaako Jarvi and Bjarne Stroustrup. Decltype and auto (revision 3). Paper N1607,
JTC1-SC22/WG21, February 17 2004. Online: http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2004/n1607.pdf; same as ANSI NCITS/J16 04-0047.

ACTUAL -
Long type declarations must be repeated verbatim every time the type is referenced in Java code. This makes the code less readable, and difficult to modify.

---------- BEGIN SOURCE ----------
See above.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Typedef can be simulated in limited cases by inheritance from generic types:

interface MyIntegerList extends List<Integer>
{
}

however, this does not scale well: It can't work for generic types that are declared 'final', and an interface type created in this way does not work as a base class for other types that may be subtypes of the original type. (For instance, if I declare the above declaration for MyIntegerList, it is not the case that I can pass an ArrayList<Integer> to a method expecting a MyIntegerList.)

In some cases, typedef can be simulated by delegation:
class MyIntegerList
{
    List<MyInteger> foo;
    // define duplicates of all necessary accessor methods here...
}

However, a class defined like this cannot participate in the original inheritance hierarchies that the original class did, which creates problems in any method passing where inheritance is necessary. Also, there is a performance penalty associated with this approach, since every access to a method of the inner 'foo' variable must go through a forwarding method in the outer class variable as well.

I do not know of any workarounds for lack of the 'auto' keyword as described above.