Project Coin Announces Final List of Small Language Changes

Posted by Charles Humble on Sep 02, 2009

Sections

Development,

Architecture & Design

Topics

Programming ,

Java

Tags

Java SE

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.”

1. Back to top

   Null handling

   by Rob Elliot

   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.

   Reply

2. Back to top

   Re: Null handling

   by Peter Veentjer

   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

   Reply

3. Back to top

   Re: Null handling

   by Rob Elliot

   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.

   Reply

4. Back to top

   Re: Null handling

   by Stephen Colebourne

   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... .

   Reply

5. Back to top

   2,3,4 Totally Pointless

   by James Richardson

   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.

   Reply

6. Back to top

   No elvis?

   by adrian collheart

   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?

   Reply

7. Back to top

   Re: 2,3,4 Totally Pointless

   by Rob Elliot

   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.

   Reply

8. Back to top

   Is that it?

   by Daniel Sobral

   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.

   Reply

• Older >