This is a weekly update on new Java 7 information. All current and previous information is maintained on my Java 7 page.
General
JavaOne is approaching fast and of course, there will be lots of forward-looking sessions related to Java 7. I’ve collected some of them at this JavaOne session page for your perusal. Unfortunately, I won’t be attending, so I’ll have to rely on all of you kind readers to keep me informed….
Java Modularity (JSR 277, 294)
The big news this week in modularity was a posting of the initial proposal for JSR 294 (superpackages) by Andreas Sterbenz. I posted some of my comments in a blog entry so I won’t belabor them here. It’s also encouraging to note that the expert group discussions for JSR 294 will be public. You can sign up for the observer mailing list or view the web archive.
Type Annotations (JSR 308)
There was an interesting post by someone (who are you?) on syntax complexity discussions on the JSR 308 mailing list. JSR 308 is an extension to annotations to allow them in a greater range of places (types and subexpressions) in Java code and this necessarily raises some possible ambiguities about where to place the annotations. I’m not sure this post really sheds much light on JSR 308 (not that it intended to) but is certainly interesting to read.
More info: JSR 308
Closures
There were a couple announcements this week regarding the FCM closure proposal (by Stephen Colebourne and Stefan Schulz). First, Stephen announced the latest version of the FCM proposal, v0.5. Second, Stephen announced a new extension to FCM for Java Control Abstraction (JCA).
One of the canonical examples for control abstraction is simulating something like a synchronized block:
Lock lock = ...
withLock(lock) {
// code protected by lock
}
Here withLock looks like a keyword (really it would be a static method used with a static import) that takes a block (or Method in FCM). In this case, the block is defined by the code inside the { } and can be any code that you would expect the caller to use. Also very important is that a return inside the block should return from the caller’s method, not from the withLock method. Other control flow constructs like continue and break should also work in their expected manner, not be interpreted in the context of the withLock method.
The FCM closure proposal has not before tried to handle control abstraction as it makes things significantly more complicated (which I think you can see in the BGGA proposal). So, I like that they have separated this out into a separate additional chunk of functionality. I see this as a “make the simple things simple (FCM) and the hard things possible (JCA)” sort of split, which is all to the good.
Lastly, Ricky Clarkson posted some opinions on whether the conflict between Neal Gafter’s BGGA proposal and Josh Bloch’s CICE proposal (both Googlers) was holding up the progress of a closures JSR. It also covers some of the thorny details between return and exception semantics in these proposals (which also relate to the example given above for FCM).
More info: Closures
Miscellaneous Ideas
In response to some comments on one of my blogs, Stefan Schulz suggested an extension to Java for meta-interfaces which would allow classes to declare that they conform to a contract of static methods. There are definitely use cases for this around factories that I think could clean up some crufty code out there.
More info: Miscellaneous ideas