网站首页 新闻首页 网页设计图形动画软件编程网站开发办公软件操作系统数据库网络技术认证考试范文资料黑客攻防 书籍教程 进入论坛

JDK 7 新特性

http://www.diybl.com/ 2008-3-21  网络 点击:  [ 评论 ]
文章搜索:    【点击打包该文章】

Improved Type Inference

i. Constructors

The addition of generics to the language greatly improved compile time type checking and largely eliminated the need for casting.  Unfortunately it also increased the verbosity of declarations, for example:

    Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

As a result, generic declarations often require multiple lines. It would be nice if you could omit the second occurrence of the type parameters (<String, List<String>>) and let the compiler figure it out ("constructor type inference"). This would remove the redundancy from the declaration, geatly enhancing readability and ease-of-use:

    Map<String, List<String>> anagrams = new HashMap<>();

See also http://gafter.blogspot.com/2007/07/constructor-type-inference.html

ii. Argument Positions

The result of a generic method, such as:

    public <E> Set<E> emptySet() { ... }

may be used on the right-hand side of an assignment:

    Set<Person> honestPoliticians = Collections.emptySet();

The compiler''s type-inference mechanism figures out that the type parameter to the emptySet invocation is Person.  It seems reasonable that the compiler should be able to infer the type when the result of such a generic method invocation is passed to another method:

    void timeWaitsFor(Set<Man> people) { ... }

       ...

    timeWaitsFor(Collections.emptySet());  // * Won''t compile!

Sadly, this is not allowed.  The specification currently requires an explicit type argument under these circumstances:

    timeWaitsFor(Collections.<Man>emptySet());

Not only are explicit type arguments awkward, but many programmers are unfamiliar with them and unable to cope when the compiler requires them.  With inference in argument positions, the explicit type argument is rarely required and the starred method invocation above becomes legal.

See also http://lampwww.epfl.ch/~odersky/ftp/local-ti.ps and http://www.javac.info/Inference.html

Enum Comparison

Enum constants can safely be compared for equality use the == operator.  All enum types implement Comparable, so it stands to reason that it should be possible to compare constants of an enumerated type for order using the <, >, <=, and >= operators.  Unfortunately, it isn''t, so programmers are forced to litter their code with calls to the compareTo method:

    enum Size { SMALL, MEDIUM, LARGE }

    if (mySize.compareTo(yourSize) >= 0)

        System.out.println("You can wear my shirt.");

If the <, >, <=, and >= operators worked for enums, this code could be replaced by the clearer:

    if (mySize >= yourSize)

        System.out.println("You can wear my shirt.");

See also http://www.javac.info/EnumCompare.html

String Switch

Information often comes into programs in string form, and some action (often translation into another form) takes place depending on the string value.  For example, the following method translates strings to boolean values:

     static boolean booleanFromString(String s) {
        if (s.equals("true&q

如果图片或页面不能正常显示请点击这里 站内搜索:   

文章评论

请您留言