Java 7 : Languages updates from Project Coin

Java Logo

I continue my posts on the new features of Java 7. In this post, I’ll detail the news coming from the Project Coin. This project has computed more than 70 new features proposal from the Java community for integration in Java 7.

In this post, I’ll detail the Final Five (or So) features chosen from this project to be included in Java 7.

Diamond Syntax

This feature is a really simple syntax improvement for generics. With that feature, you can avoid to write twice the generics type in a generics declaration. A little example :

Instead of writing this :

Map<String, Collection<Integer>> map = new LinkedHashMap<String, Collection<Integer>>();

You can now write that :

Map<String, Collection<Integer>> map = new LinkedHashMap<>();

That’s really practical, but not essential.

Simplified Varargs Method Invocation

This improvement is not a new functionality, but only a move of a warning. Like you must know, we cannot create arrray of generics type because the type verification is not made at the same time. But with the Ellipse of Java 5, you can made that type of array implicitely and the compiler generate warning at each invocation of that kind of method, so the warning has moved to the method declaration to have less warnings.

Integers declaration

You’ll can declare integers using binary values :

int binary = 0b11001001001;

and you can use _ (underscores) in the declaration :

double amount = 1_999_888_777.25;
int color = 0xdd_dd_dd;
int binary = 0b110_0100_1001;

That’s allow to make more verbose code, but it’s only sugar.

Collections manipulations and declaration

Another improvements to code verbosity, is the support of collections in the language. You’ll have code facility to access and edit indexed collections like list and maps and to declare easily collections.

First, you can access to an element using the same syntax as the array :

List<String> list = ...;
Map<String, String> map = ...;
 
String firstValue = list[0];
 
map["Test"] = firstValue;
 
String valueFromMap = map["Test"];

For the maps, that works with any type of key. So if you have one of your class for key, you can directly pass it in the code like the Strings in my example.

And, you can also quickly declare collections like array :

Lists with [] :

List<Integer> numbers = [ 1, 2, 4, 8, 16, 32, 64, 128 ];

Sets with {}

Set<Integer> numbers = { 256, 512, 1024, 2048, 4096 };

And Maps with {} and : to split value and key :

Map<String, String> translations = {
  "Hi" : "Bonjour",
  "Goodbye" : "Au revoir",
  "Thanks" : "Merci"
};

All that created collections are immutables.

Strings switch

A really good feature : Switch with Strings values. You can now do that kind of switch : ¨

String value = "";
 
switch (language) {
  case "fr":
    value = "Bonjour";
    break;
  case "en":
    value = "Hi";
    break;
  case "de":
    value = "Guten tag";
    break;
  default:
    value = "Hello";
    break;
  }

I thinks, it’s really great. With that, we can delete a lot of ugly list of if/else if code.

Automatic Resource Management (ARM)

Another great feature, you can automatically close the resources using a new try clause :

public void write(URL url, File file) throws IOException {
  try ( FileOutputStream fos = new FileOutputStream(file); InputStream is = url.openStream() ) {
    byte[] buf = new byte[2048];
    int len;
    while ((len = is.read(buf)) &gt; 0) {
      fos.write(buf, 0, len);
    }
  }
}

In that code, the FileOutputStream and the InputStream will automatically be closed after the try, making a cleared code and you cannot forgot a resource with that.

And last, the modifications to support the JSR 292 directly in the language. I’ve already described that features in other post : Java 7 : More Dynamics

That’s all for these new language enhancements from the Project Coin.

For me, i like the new ARM and the Strings Switch, but i think this is simple enhancements, they were others proposals in the Project Coin i found better, like the “Improved Exception Handling for Java”, “Improved Wildcard Syntax for Java” or “Elvis and Other Null-Safe Operators”, but this a good start.

Related posts:

  1. Java 7 : Add “public defender methods” to Java interfaces
  2. JDK 7 Features updated ! Plan B has apparently been approved
  3. Java File Copy Benchmark Updates (once again)
  4. Java SE 6 Update 21 Released
  5. JTheque Utils 1.1.5
  • http://coffeebean.loicdescotte.com Loic

    Great post!
    Unfortunate that the implicit getter/setteer accessors on properties have been abandoned for Java 7 …

    • Baptiste Wicht

      I’m not a great fan the properties proposal. It’s not to heavy to implement all getters/setters directly and we can add more than simply get/set features like checks on the value.

      But it will make the code clearer, so i don’t know what to think about that.

      • Frits Jalvingh

        As is common you have not grasped the main reason for having first-class property support. It is not the replacement of getters and setters with other syntax; it is to get /property references/: references to properties that are compile-safe, so that we are no longer forced to use strings as property names. Something like:

        criteria.add(Restrictions.eq(User#email, “[email protected]”));

        and

        Property emp = User#email;
        emp.setValue(uinst, “[email protected]”);

        This allows compile-time checking of property names, and makes lots of frameworks way more robust. No more runtime failure after a property rename; impact analysis for property removal etc, etc..

  • http://coffeebean.loicdescotte.com Loic

    Great post!
    Unfortunate that the implicit getter/setteer accessors on properties have been abandoned for Java 7 …

    • Baptiste Wicht

      I’m not a great fan the properties proposal. It’s not to heavy to implement all getters/setters directly and we can add more than simply get/set features like checks on the value.

      But it will make the code clearer, so i don’t know what to think about that.

      • Frits Jalvingh

        As is common you have not grasped the main reason for having first-class property support. It is not the replacement of getters and setters with other syntax; it is to get /property references/: references to properties that are compile-safe, so that we are no longer forced to use strings as property names. Something like:

        criteria.add(Restrictions.eq(User#email, “[email protected]”));

        and

        Property emp = User#email;
        emp.setValue(uinst, “[email protected]”);

        This allows compile-time checking of property names, and makes lots of frameworks way more robust. No more runtime failure after a property rename; impact analysis for property removal etc, etc..

  • Dimitri

    Hm. It seems that Java has started to steal features from C#.

    • Baptiste Wicht

      C# has also steal features from other languages and certainly from Java too.

      That’s a good things to get features in other languages to improve Java, I think.

  • Dimitri

    Hm. It seems that Java has started to steal features from C#.

    • Baptiste Wicht

      C# has also steal features from other languages and certainly from Java too.

      That’s a good things to get features in other languages to improve Java, I think.

  • http://ocpsoft.com Lincoln

    I love it! The collections syntax is sweet! Finally!

    Now I just want my multi-conditionals ;)

    • Baptiste Wicht

      What do you mean with “multi-conditionals” ?

  • http://ocpsoft.com Lincoln

    I love it! The collections syntax is sweet! Finally!

    Now I just want my multi-conditionals ;)

    • Baptiste Wicht

      What do you mean with “multi-conditionals” ?

  • Mohamed El-Beltagy

    In regards to ARM; I have the following questions:
    1- Does this mean that the new try syntax will have a semicolon separated list of resources to be managed?
    2- What if I declared a resource before the try and used inside the try? Will it still need to be manually closed?
    3- Does this means that I can now declare a try statement (without a resource to manage) and have no catch or finally blocks?

    I tried to look for some resources on Sun.com about the ARM that talks about these things, but cannot find any. If you have a place to take a look at, please point me to it and I would be very thankful. :)

    • Baptiste Wicht

      1. Exactly
      2. Yes, if you don’t add the resources to the list, you have to release it manually
      3. No, you can only declare a try without a catch if you declare a list of resources

      You can look at the proposal : http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

      • Mohamed El-Beltagy

        Thanks Baptiste for your reply and the link.. :)

        • Baptiste Wicht

          You’re welcome :)

  • Mohamed El-Beltagy

    In regards to ARM; I have the following questions:
    1- Does this mean that the new try syntax will have a semicolon separated list of resources to be managed?
    2- What if I declared a resource before the try and used inside the try? Will it still need to be manually closed?
    3- Does this means that I can now declare a try statement (without a resource to manage) and have no catch or finally blocks?

    I tried to look for some resources on Sun.com about the ARM that talks about these things, but cannot find any. If you have a place to take a look at, please point me to it and I would be very thankful. :)

    • Baptiste Wicht

      1. Exactly
      2. Yes, if you don’t add the resources to the list, you have to release it manually
      3. No, you can only declare a try without a catch if you declare a list of resources

      You can look at the proposal : http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

      • Mohamed El-Beltagy

        Thanks Baptiste for your reply and the link.. :)

        • Baptiste Wicht

          You’re welcome :)

  • http://horstmann.com Cay Horstmann

    Did you try running your examples with the JDK7 beta? It’s interesting to see which ones work.

  • http://horstmann.com Cay Horstmann

    Did you try running your examples with the JDK7 beta? It’s interesting to see which ones work.

  • http://www.javathehut.org Kent

    How about adding support to make regex expression literals much easier?

    • Baptiste Wicht

      For what I know, there is no improvements on the regex literals.

      What problems have you with the Regex literals ?

  • http://www.javathehut.org Kent

    How about adding support to make regex expression literals much easier?

    • Baptiste Wicht

      For what I know, there is no improvements on the regex literals.

      What problems have you with the Regex literals ?

  • Frits Jalvingh

    What a joke… More than 3 years and this is what is presented as improvements…. They are not: they are minor fixes of negligible value! All important proposals have been refused and we are left with this. Java is dying from neglect, and from horrible choices.

    Young people are considering Java the new Cobol – a dying old-fashioned language that is no fun to work in. And they are right. Luckily the Java ecosystem is huge so it’s death will take a long time. But it will come soon enough if this stagnation does not stop.

    It’s actually very, very sad. It is very possible to extend your language in new ways as C#’s history shows you. Its versions add possibilities that Java’s designers apparently do not understand- so they see no value. If you leave idiots to design your language you get one only an idiot will use.

    Let’s hope Oracle’s takeover of Sun will out Java’s current stewards and bring in new blood- with brains and vision. Although I fear, knowing Oracle’s tracksheet, that this will prove not to be the case.

  • Frits Jalvingh

    What a joke… More than 3 years and this is what is presented as improvements…. They are not: they are minor fixes of negligible value! All important proposals have been refused and we are left with this. Java is dying from neglect, and from horrible choices.

    Young people are considering Java the new Cobol – a dying old-fashioned language that is no fun to work in. And they are right. Luckily the Java ecosystem is huge so it’s death will take a long time. But it will come soon enough if this stagnation does not stop.

    It’s actually very, very sad. It is very possible to extend your language in new ways as C#’s history shows you. Its versions add possibilities that Java’s designers apparently do not understand- so they see no value. If you leave idiots to design your language you get one only an idiot will use.

    Let’s hope Oracle’s takeover of Sun will out Java’s current stewards and bring in new blood- with brains and vision. Although I fear, knowing Oracle’s tracksheet, that this will prove not to be the case.

  • http://www.concretestained.net Concrete Grinding MIAMI

    In that code, the FileOutputStream and the InputStream will automatically be closed after the try, making a cleared code and you cannot forgot a resource with that.

  • http://www.facebook.com/people/Anatoly-Ivanov/100001048476476 Anatoly Ivanov

    nice

  • http://www.moldremoval.org Mold Removal Elmira

    Damn! This could be my best crackpot idea of all time!!

  • Zing

    I don’t know why they are so adverse to adding general objects into switch. Practically every other modern language has the feature by now, and it’s a handy shortcut compared to a giant if-else where every line is the same equals() comparison with a different object. :/

    The dumbest thing about it is that the code they generate for the String-switch will be *exactly* the same as the code they would be generating to support any object, because the only way to do the equality on strings is equals() anyway.

  • http://www.findprefab.com Panelized Homes Houses

    String switch is great. Thanks for the great post.

  • Anonymous

    ARM is my favorite feature on JDK7 which reduce writing some boiler plate code, which is core mission of java. I also found
    example of automatic resource management quite useful