BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon London

Adopt the right emerging trends to solve your complex engineering challenges. Attend in-person or online.
QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Project Coin Announces Final List of Small Language Changes

QCon New York (June 13-15): Learn best practices from senior developers at early adaptor companies.

Project Coin Announces Final List of Small Language Changes

This item in japanese

Bookmarks

Sep 02, 2009 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Joseph Darcy has published Project Coin's final list of approved changes to the Java language for the forthcoming version 7 release. They are:

  1. Automatic Resource Management: Provides a mechanism for resource clean-up. An ARM block is analogous to C#’s using statement but based on a form of the try statement. As a result, whilst the using statement only takes a single resource, ARM is able to handle multiple resources within the scope of a given block.
  2. Better Integer Literals: Adds support for binary literals and underscore separators in numbers to aid readability - for example
    long creditCardNumber = 1234_5678_9012_3456L.
    May also include improvements to the handling of unsigned literals if a solution can be found in time.
  3. Collection Literals: Adds support for immutable list, set and map literals with a syntax similar to that of array initialisers, and may also add support for indexing access to lists and maps.
  4. Improved Type Inference for Generic Instance Creation (< > or diamond): Uses limited type inference for class instance creation so that where parameterise types need to be explicitly declared for a constructor, but they could be ascertained from the context, then they can be replaced with an empty set of type parameters. Thus instead of writing:
    Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
    You could write:
    Map<String, List<String>> anagrams = new HashMap<>();
  5. Language support for JSR 292 including invokeDynamic instructions, method handle invocation, certain relaxed conversions and exotic identifiers.
  6. Simplified Varargs Method Invocation: A compiler change for warnings which are issued when a method combines varargs with non-reifiable array types. The change moves the warning from the call site to the method declaration.
  7. Support for Strings in Switch Statements.

The majority of these proposals are expected to be in JDK 7's development Mercurial repositories by the end of October 2009.

Three short-listed proposals that haven't made the final cut are Improved Exception Handling for Java, Elvis and Other Null-Safe Operators and Large arrays.

Joseph Darcy commented:

“Improved exception handling would be a fine change for the language, but it ventures near the type system and we do not estimate we have resources to fully develop the feature within JDK 7. I would like to see improved exception handling reconsidered in subsequent efforts to evolve the language. While the Elvis operator and related operators are helpful in Groovy, differences between Groovy and Java, such as the presence of primitive types and interactions with boxing/unboxing render the operators less useful in Java. JDK 7 will support other ways to ease the pain of null-handling, such as the null checking enabled by JSR 308. Aggregates natively supporting more than 32-bits worth of entries will no doubt be increasingly needed over time. Language support for collections may allow such facilities to be developed as libraries until the platform directly handles large data structures.”

Rate this Article

Adoption
Style

This content is in the Java topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Null handling

    by Rob Elliot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Does anyone else's heart sink at how utterly ugly and absurdly verbose Java is going to be when JSR308 has us putting @NonNull all over our code? In my opinion it's a dreadful solution to the problem of null handling.

    Back to top
  • Re: Null handling

    by Peter Veentjer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree.

    A few years ago I have been playing with a programming language that runs on the JVM called Nice:
    nice.sourceforge.net/


    And one of the cool things was that the solved the null pointer problem from within the typesystem (not that difficult) and they also have a cool syntax.


    Person p1; //p1 can't be null, it can only refer to a person instance
    ?Person p2;//p2 can be null or refer to a person instance.


    So just slap a question mark in front of it to indicate that it can be null. The default is that a ref can't be null and in most cases this is the behaviour you want.


    So the @NotNull is just ugly... perhaps that IDE's can make the syntax appear less horrible.


    Peter Veentjer
    Multiverse Software Transactional Memory

    Back to top
  • Re: Null handling

    by Rob Elliot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's much nicer - Stephen Colebourne of Joda time fame has suggested something similar for the Fan programming language, but with the ? after the type (so Person? p2 rather than ?Person p2). Either is much less verbose, completely intelligible and works nicely with the research that shows that c. 2/3 of variables are never intended to be null so "not null" should be the default. Of course you couldn't put that solution into Java because it would not be backwardly compatible with old code; but I personally feel the @NotNull solution is actually worse than the problem. Code is so cluttered with verbose annotations now that it's very difficult to see the intent.

    Back to top
  • Re: Null handling

    by Stephen Colebourne,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Stephen Colebourne of Joda time fame has suggested something similar for the Fan programming language


    This has been implemented in Fan - www.fandev.org/doc/docLang/TypeSystem.html#null... . I also suggested something for Java a long time ago, which I believe to be a lot nicer than @NotNull - www.jroller.com/scolebourne/entry/java_7_null_s... .

    Back to top
  • 2,3,4 Totally Pointless

    by James Richardson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Given that google collections gives you 3 & 4 already, and even if it didn't, you could write it yourself in 1 line of code, changing the language to support this stuff seems like a massive waste of time.

    Surely there is something better that could be done... like sorting out the generic type nonsense.???

    Perhaps Sun just don't have the skills anymore, and thats why they won't go near the type system - they know that they will just make it worse?

    Additionally - Null checking is a programmer issue. Just don't make any - then you wont have any problems.

    Back to top
  • No elvis?

    by adrian collheart,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm very sad that Elvis left the building. I love some of the other changes, especially ARM (Java got it only some 15 years after C++, but better late than never) and collection literals.

    But Elvis was by far the most anticipated feature and also the one that seemed to have the most support. Anyone know what caused this feature to be scrapped?

    Back to top
  • Re: 2,3,4 Totally Pointless

    by Rob Elliot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I tend to find that the vast, vast majority of my code is working with other people's code, often in the form of APIs. So me not making nulls doesn't really solve the problem.

    Back to top
  • Is that it?

    by Daniel Sobral,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    JSR292 is welcome. The rest is... the rest is something that doesn't merit the "7". It could all be slipped in a minor release. There's no structural improvement to Java, just cosmetics and minor LoC reductions.

    Whatever. Let Java die, there are alternatives already.

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT