Java 7 Roundup (Mar 13th)
This is a weekly update on new Java 7 information. All current and previous information is maintained on my Java 7 page.
Java Modules (JSR 277, 294)
Glyn Normington posted a great overview of the various efforts around Java modularity that are currently in progress. This post ties together the JSR 277 and 294 specs which are working on build modularity into the Java language for Java 7 and also covers the OSGi JSR 291 which has been the source of source recent controversy. Glyn is somehow involved in all of these, so he obviously has an informed opinion that is worth your time if you care about such things. Neil Bartlett responded to Glyn’s post and expressed skepticism that more support was needed beyond what OSGi already offers. Glyn responded himself to argue that support for modularity is needed in the language and that this is complementary to what OSGi provides, not essential. Glyn also posted some info on how classloaders might change with JSR 277.
I have done some work with Eclipse/OSGi and I think that there definitely is a case to be made for embedding more support for access constraints at the module (multi-package) level directly in the language. I think what OSGi does is in general fairly great but I frequently see use cases where I want to mark a set of packages as “hidden” within a module or have need for a simple plugin-loading system (simpler than needing bundles, manifests, and all the rest of the junk that goes along with OSGi).
Beans binding (JSR 295) and the Swing Application Framework (JSR 296)
With all the desktop Java conferences going on, it was inevitable that we would see some interesting desktop Java 7 news this week. Probably the most visible news is Roman Strobl’s demo of beans binding and the SAF which starts to tie together the Java 7 Swing efforts in a public way for the first time.
Daniel Stephan posted on various data binding frameworks such as JGoodies and JFace and how they compare to JSR 255.
Shannon Hickey announced he’s taking over for Scott Violet as the spec lead on JSR 295 and that it’s “almost ready” for public release.
Closures
In the wake of the activity after the FCM proposal was released, Neal Gafter posted on how we should be comparing closure proposals not just by point examples they all can do but on the expressiveness that they allow and what new avenues the more powerful proposals like BGGA might open up.
More info: Closures
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Hi, could you clarify what this means: “simpler than needing bundles, manifests, and all the rest of the junk that goes along with OSGi”
“Bundle” is the OSGi terminology for a module, and you can hardly have a module system without modules.
Manifests you have already any time you create a Jar. OSGi adds a few lines of metadata, such as the module name and the dependencies. Again, you can’t have a module without metadata.
And the other junk… what other junk? That’s all there is!
Hi Neil, you’re right, I was being lazy. I had actually written a longer more detailed version of this, but lost it somehow in the browser and I was too tired to fully rewrite.
What I was trying to say was, I would like some way to declare (in my source) the existence of modules. I want those constraints enforced (with respect to package visibility) at compile-time and run-time by javac and java without the need for a separate OSGi runtime. This (may) be completely independent of how I actually package my app. I think this might map into what JSR 294 is addressing, although I’m not totally clear on the boundaries between 277 and 294.
The other item, which may not be feasible, is the ability to look up (dynamically) all implementors of an interface. This is critical for any kind of dynamic plugin architecture and is something that you can get in OSGi through extension points. It’s obviously complicated in Java by the fact that classes are loaded as needed, so it may be impossible to answer this question without actually scanning the entire classpath or doing something that would have performance or logistical problems.
Those are the two issues that I’ve hit repeatedly and looked to something like OSGi to solve. I think the first one can and should be handled as part of the platform, regardless of packaging. It’s possible that Java modules would allow me to handle the second as well, but I haven’t seen enough to know yet.
I apologize for the word “junk” which is not really fair (I didn’t mean it pejoratively) which I was using as a shorthand for “stuff above the Java platform”. And I was also thinking of the meta files that come out of using Eclipse projects, more than OSGi.
Thanks for keeping me honest…. :)