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.

Comments:

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.

Alex

Posted by Alex Blewitt on September 24, 2010 at 05:10 AM PDT #

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)) {
___doSomethingUseful();
} // 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) {
___lockImpl(locks);
___return new AutoCloseable() {
______@Override
______public void close() {
_________Locker.unlock(locks);
______}
___}
}

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

Thanks,
Jason

Posted by Jason Moore on September 28, 2010 at 07:20 AM PDT #

@Jason,

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.

Posted by Joe Darcy on September 28, 2010 at 07:49 AM PDT #

@Alex,

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.

Posted by Joe Darcy on September 28, 2010 at 10:33 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll