Feature request: aliasing classes at import

[joe.darcy at oracle.com]

On 7/14/2011 11:17 PM, Ben Evans wrote:
> On Fri, Jul 15, 2011 at 1:52 AM, Kelly O'Hair <kelly.ohair at oracle.com 
> <mailto:kelly.ohair at oracle.com>> wrote:
>
>
>     Kind of looks like C macros:
>
>     #define UDate java.util.Date
>     #define SDate  java.sql.Date
>
>     Oh, that would be bad right?  Did someone say Java shall not have
>     macros? ;^)
>
>
> Well, in this case, I think the OP's intention was that these import 
> aliases would be scoped to a single file, rather than global textual 
> replacement.
>
> I think that it would be fine if all it does is provide an 
> alternative, non-clashing short name for a class.
>  
> This is very similar to a feature of Scala's import statement, by the way.
>
> Joe: What's the process for Java 8 Coin changes? Are we at a stage 
> where you want actual proposals and strawman prototypes yet (assuming 
> you're going to be carrying on the work you did for 7 in the JDK8 
> project)?
>
> Thanks,
>
> Ben

Catching up on email, given the scope of language changes coming with 
Lambda, I would not expect JDK 8 to be able to accommodate another full 
set of Coin changes as done in JDK 7.  Personally, I would certainly 
like to see collections literals in the language at some point; I think 
they would help declutter common code patterns.

For JDK 8 planning in general, JEPs will be involved [1].  However, 
independent of the particulars of JDK 8 planning, I would certainly 
encourage interested parties to develop prototypes of Java language 
changes, paying mind to all the possible interactions [2] and expected 
test development [3].

Cheers,

-Joe

[1] http://mail.openjdk.java.net/pipermail/discuss/2011-June/001962.html
[2] http://blogs.oracle.com/darcy/entry/so_you_want_to_change
[3] http://blogs.oracle.com/darcy/entry/javac_regression_tests