One issue with generic which show pretty much immediatly when you start 
using them, is that it would be immensely practical to have some kind of 
alias statement, like C/C++ typedef.

Consider this code:

public class Example1 {
   private List<Pair<String,String>> internal;

   public Example1() {
     internal = new LinkedList<Pair<String,String>>();
   }

   public Collection<Pair<String,String>> getInternal() {
     return new HashSet<Pair<String,String>>(internal);
   }
}

This is both painful to read, and painful to write. Compare with this:

public class Example2 {
   public alias StringPair Pair<String,String>;

   private List<StringPair> internal;

   public Example2() {
     internal = new LinkedList<StringPair>();
   }

   public Collection<StringPair> getInternal() {
     return new HashSet<StringPair>(internal);
   }
}

As I see it, this would greatly reduce typing, and increase readability. 
The feature is not hard to implement, since it only concerns compile time 
transformation. The only issue would be that of a new key word, but this 
alternate syntax could get away from that too:

public StringPair = Pair<String,String>;
Posted Date : 2006-11-20 21:36:17.0

N/A

One of many requests for aliasing/implicit typing of long type names, especially those involving generics.
Posted Date : 2006-11-20 21:36:17.0

While I don't necessarily agree with the proposed syntax, I wholeheartedly agree that a typedef-like mechanism would be very nice to have.

I think this feature would be quite useful.  However, I might do:

alias type alias_name;

instead of:

alias alias_name type;

Also, it would be great if the compiler generated errors based on whatever the offending variable was defined as (display only the alias name if that was used to define the variable).  There could also be a compiler option that would turn off this feature and display the entire type name on error.

--Kevin
galabar@hotmail.com

I think this is a good idea.  I prefer the alias type alias_name; syntax.

One thing.  If this is to be included, I don

What the???  Anyway.  These shold be implicitly private.  I don't want to deal with code that imports aliases from other classes.

It will be a very nice addition to the language.
It would be better to name the new keyword "alias" because "typedef" can induce C / C++ programmers to use it as a substitute for proper class declaration. (Using the "=" signal  for aliasing is reminiscent of the syntax for abstract methods in C++ - "= 0" - that's not very clear.)
An unrelated, but very common use of "alias" is desirable when you are using two classes with the same name but different packages (like java.util.Date and java.sql.Date).

This desire comes up pretty quickly when using Generics, and you want to keep your lines < 80 characters.

To ease concerns of code readability these typedefs must always be private, and should be limited to template definitions (the import problem with Date can almost always be solved with a specific import statement).  

I don

I do not know why you would use another word like "alias" though, when "typedef" has been around for decades.

"alias" is preferrable to "typedef " since you are not defining a type. In C++ you can say typedef struct { ... } name and hence define and name at the same time. I think all we want is a syntactic sugar to avoid having to replicate the generic type definition everywhere it is referenced.

Maybe an alias should also be scoped: public, private etc.

I think if we employ the following syntax instead:

<T> = <Pair<String, String>>;

in which the compiler would consume the statement and would "remove" it much like type erasure for Generics, then it would be more preferable as:

1) no new keywords introduced into the language
2) the assignment can still follow the scopes in the code

Another possibility is to make this a feature in Annotation, which would also be a good idea~

You can actually fake most of this behaviour using empty inheritance:

import java.util.*;

public class Example3 {
	
	public interface StringMap extends Map<String, String> {}
	
	private List<StringMap> internal;

	public Example3() {
		internal = new LinkedList<StringMap>();
	}

	public Collection<StringMap> getInternal() {
		return new HashSet<StringMap>(internal);
	}
}

There are limitations with this, such as not being able to cast from the original type to the alias. But in most circumstances this may not be an issue.

The annotations idea is a good one if you could get IDE support for it (So that auto-complete would work, etc.). It would require using apt to specially compile the source code. 

alias.  Very nice solution.  Proof new keywords and not silly annotations will continue to drive the language :)

i wholeheartedly support this RFE. On the issue of the order of the type name and its definition, "alias Name generictype" is closer to "interface Name extends generictype" and to class definition syntax, which are types too, albeit concrete implementations of a specific type. And even to field declarations, eg. "int myVar = .." That is to say, the "naming" usually follows the keyword, and the definition then follows the naming. 

It's nearly 2008 and there is still no way to define an alias. Would be nice to see this as a new feature in Java SE 7.

most comments here would just safe some typing and thus is nice to have
a much better argument for an alias/typedef construct is 9) in bug: 6368038 which would really add additional compile-time type-safety

Could we also/instead do this in the import section?

import com.foo.Enquiry;
import com.bar.Enquiry as BarEnquiry;
import java.util.List<String> as StringList;

this way variable name clashes (with new keyword 'as' or 'alias')  within the class body would not necessarily be a problem as it's limited to the imports...

5 years and we still don't have this? This is such a simple thing to add. And it doesn't change the language at all, just the compiler (which would simply do a search & replace before compiling)