Proposal: Import Aliases for Classes and Static Methods
reinier at zwitserloot.com
Fri Mar 6 07:09:57 PST 2009
package imports would solve all these problems no, and be simpler to
My major concern with type aliases is code snippets: When people post
a snippet, they almost never include import statements. Many IDEs ship
out-of-the-box as collapsing import statements but nothing else. They
aren't generally considered important to grok any code snippet. But
with type aliases, that changes. Note that anybody casually perusing a
complete source file is effectively still 'reading a snippet', so to
speak, though at least an IDE can help and e.g. jump to the proper
class when ctrl+clicking the type, or showing the complete type in a
You don't have that problem with package imports. "sql.List" is about
as easy to type as "SQLList", and it does not create the inherent
confusion in the name that "SQLList" has; I would interpret any type
named "SQLList" as "A List contain SQLs, whatever those are".
Someone else will need to adapt or rewrite a proposal (my plate is
full). Package imports don't help if the only difference in the FQN is
near the front, but I don't know of any two commonly used classes
together that differ only near the front. (e.g. sunw.io.Serializable
vs. java.io.Serializable can't be simplified with package imports,
but, nobody uses sunw.*, so not a relevant use case).
On Mar 6, 2009, at 05:50, Phil Varner wrote:
>> Static import was surprising complicated in JDK 5. While these
>> aliases could alleviate some problems, I think they would be easily
>> 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
> Thanks for pointing this out, it's definitely a huge hole in the
>> The Javapolis discussions of 2007 ended with the majority of
>> participants choosing against aliasing of imports (typedefs).
> 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
> Machines might be interesting, but people are fascinating. -- K.P.
More information about the coin-dev