Proposal: Import Aliases for Classes and Static Methods

[Phil Varner]

> Static import was surprising complicated in JDK 5.  While these aliases could alleviate some problems, I think they would be easily abused
> and even when not being abused render code less readable.
> IMO, having alternate names for potentially common classes would be less readable.

I agree for common classes this could be a problem, but I don't think
it would be any less of a problem than the existing support for
wildcards.  I see this more as a solution targeted mostly for long
package names with overlapping class names.  I'm going to need to
think some about what "readable" really means, and would be interested
in any thoughts on this topic.

> While grammar changes are part of the picture, the substantive changes would be to JLSv3 section 6.5 "Determining the Meaning of a Name":

Thanks for pointing this out, it's definitely a huge hole in the proposal.

> The Javapolis discussions of 2007 ended with the majority of
> participants choosing against aliasing of imports (typedefs).
>
> http://www.javapolis.com/confluence/plugins/advanced/gallery-slideshow.action?pageId=32793&decorator=popup&imageNumber=9

Thanks for the pointer.  I, too, would probably vote against a the proposal of
import Map<String,Integer> as CodeValueMap;

Several of the related bugs mention this syntax, but I think this
combines two issues together.  It seems to me that the simple mapping
of a fully-qualified class name to a "short" name is separate from the
typedefing of a specifically-parameterized generified type to a short
name.

--Phil

-- 

Machines might be interesting, but people are fascinating. -- K.P.