Feature request: aliasing classes at import
serge.boulay at gmail.com
Thu Aug 4 18:56:12 PDT 2011
"Personally, I would certainly like to see collections literals in the
language at some point; "
I was under the impression that this was already voted on in the Java 8 JSR
To quote JSR 337
"Java SE 8 will further reduce boilerplate code by adding productivity
features to the Java language and the Java SE APIs. These features will
increase the abstraction level of most applications in a pragmatic way, with
no significant impact on existing code and a minimal learning curve for all
developers. We propose to make it easier for developers to work with the
existing, *widely-used Collections Framework, for example, by extending the
language with literal expressions for immutable lists, sets, and maps*."
On Tue, Aug 2, 2011 at 7:44 PM, <joe.darcy at oracle.com> wrote:
> 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
>> 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
>> 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)?
> 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 . 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  and expected test
> development .
>  http://mail.openjdk.java.net/**pipermail/discuss/2011-June/**
>  http://blogs.oracle.com/darcy/**entry/so_you_want_to_change<http://blogs.oracle.com/darcy/entry/so_you_want_to_change>
>  http://blogs.oracle.com/darcy/**entry/javac_regression_tests<http://blogs.oracle.com/darcy/entry/javac_regression_tests>
More information about the jdk8-dev