Musings on JDK development

Project Coin at JavaOne 2010

This morning and early afternoon Maurizio and I gave our JavaOne talk about Project Coin to a packed room; the slides for the talk are now available. The NetBeans demo of Coin support also went smoothly.

As announced earlier at JavaOne, we'll be following the "plan B" option for JDK 7 so the accepted Coin features that are not currently implemented will be reconsidered for JDK 8.
In the meantime, we're interested to have more feedback on the Project Coin features

  • Improved numeric literals

  • Strings in switch

  • Reduced varargs warnings

  • Diamond operator

  • Multi-catch with more precise rethrow

  • try-with-resources statement

that are available to test out now in JDK 7 builds.

Join the discussion

Comments ( 4 )
  • Alex Blewitt Friday, September 24, 2010

    Great talk. I wrote up a piece on InfoQ (at http://www.infoq.com/news/2010/09/what-lies-beneath) with links back to this presentation as a good example of how complex JSRs can be. Please let me know if I've made any mistakes or you want me to change anything.


  • Jason Moore Tuesday, September 28, 2010

    Let me first say, love the changes. I did have a question about the try-with-resources call. In particular I don't want to throw an exception from my close operation, it will never fail, but if I fail to catch any exception the compiler yells of course of a try without catch. Did I misread the documentation, or is this suppose to be correct behavior? I would like the user code to look like this:

    try (Locker.getLocks(locks)) {


    } // Auto unlock

    Here is the code that I am basically using inside getLocks, notice the close method does not throw any exceptions.

    public static AutoCloseable Locker.getLocks(final ReentrantLock ... locks) {


    ___return new AutoCloseable() {


    ______public void close() {





    Sorry for having to use the _ character for spaces, it seems this blog doesn't like leading spaces...



  • Joe Darcy Tuesday, September 28, 2010


    Ah, I see what is going on. To get the desired exception behavior, i.e. to get the compiler to understand the close method will not throw an exception, the Locker.getLocks method needs to be declared to return some AutoCloseable subtype that is declared to not throw an exception. If the compiler just sees an AutoCloseable, it has to assume Exception can be thrown.

  • Joe Darcy Tuesday, September 28, 2010


    A few comments on your article, the Project Coin form for strings in switch goes into more technical depth than is usually included in a JSR proposal, for comparison see JSR 201 "Extending the Java(TM) Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import" (http://jcp.org/en/jsr/detail?id=201). However, during the course of a language change JSR, the sort of details called for in the Coin proposal form, amongst many others, get identified and worked out.

    A more charitable description of the work done by an \*umbrella JSR\* is that it aggregates rather than "white washes" the work of component JSRs.

    In no way taking away from the work done by Bob Lee and the JSR 330 expert group, a precondition for a JSR being able to move as quickly as 330 did is that there is an existing body of work to use as a reference point. Without years of experience with Guice and other DI frameworks, a JSR for DI would not be able to move nearly as quickly since much more of the JSR would have to be invented rather than standardizing or building on some aspects of existing practice.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.