This is a weekly update on new Java 7 information. All current and previous information is maintained on my Java 7 page.

The biggest JDK news in the last week is that the Open JDK 6 will be based on Open JDK 7! I guess after having gone through all the conversion and legal effort for Open JDK 7, this was an easier path than going through it all again with JDK 6.

It looks like in the next build of JDK 7 (b20), there will be a newly split out workspace for langtools (javac, javadoc, javap, javah, and apt). langtools will have its own Ant-based build and is split into projects for each tool. If you want to hack on the tools, you should be able to do that without downloading and compiling the whole JDK – the langtools are a standalone workspace. They’ve also managed to get rid of the recompile step in the normal JDK build as a result. Also, the intent is that KSL (the Kitchen Sink Language project) will be restructured such that it uses the same build system as the langtools in the JDK, to make it even easier to move from KSL into langtools.

Modularity

Glyn Normington posted about the JSR 277 expert group and his frustrations in examining possible interop between JSR 277 and JSR 291 (OSGi). In the Java 7 world, JSR 277 has become my biggest question mark in terms of the future of the language. The manner in which the spec has been developed has felt pretty closed so far and at times they give the impression that yeah the OSGi guys have something but they should let somebody who really understands things design something better. And sometimes the OSGi folks can sound a bit like OSGi is the ultimate in module solutions (it slices, it dices, it imports modules!). I don’t really think either of those positions is truthful and I don’t even think the people assigned to either side of this debate even necessarily believe those things – that’s more of an impression. I think in general all the people involved in these efforts want to make something great but somehow the communication has broken down a bit.

The Java Posse has been discussing JSR 277 / 291 off and on in recent episodes but thus far their discussions have been disappointingly void of the detail needed in this discussion. The Java community as a whole needs to be paying more attention to what’s going on here and asking questions before it’s too late to ask them. I think the Posee is one of the most visible and trusted focal points of Java discussion in the community and I’d like to call on them to dig into 277/291 a bit more. I’d love to hear some detailed discussion of the details of the specs and proposals. Or interviews with people like Stanley Ho, Andreas Sterbenz, Glyn Normington, Neil Bartlett, or Bryan Atsatt.

And I’d love for you, dear reader, to look at the specs and the mailing lists and the code out there and take an interest because this is going to affect us all in our daily work, more so than any other change to Java 7 I can think of. It will change how we structure, manage, and deploy our code. If we do it right, it will support us and let us build the true Java equivalent of CPAN or Ruby Gems. If we do it wrong, it will make deployment and version management and JAR hell even worse than it is now. It’s crucial to get this right as it’s going to be baked deeply into our language, our libraries, and our tools. Right now, things are malleable, but that won’t be true for long.

More info: JSR 277

Swing

Shannon Hickey has released JSR 295 Beans Binding version 1.0. As you may recall, the last major revision was met with a healthy dose of skepticism and Shannon took it in stride, making some significant changes to address those issues. Perhaps the most obvious one was that the proposal was reworked so that it no longer requires the use of EL (the expression language). That implementation is still provided but is not required by the API.

There is a lot of interesting discussion occurring in the comments as well, particularly between Shannon and Mikael Grev. One thread is about whether properties in the bean bindings are stateless or stateful and ways to make the difference apparent in the API. And another interesting thread is about mentions of an internal property support language proposal. Things have been quiet on the property language front for quite a while, so perhaps we are close to a new proposal and a new flurry of discussion.

More info: JSR 295

JMX

Jean-Francois Denise posted on securing the JMX connector with WS-Security as a follow up to his previous post on securing the JMX connector with SSL.

More info: JSR 262

Language Proposals

Glyn Normington posted about operator overloading for decimals looking for support. Separately, I traded emails with someone this week who was asking about operator overloading as a generic feature in Java and whether it would ever happen. My guess was no, but I’d be interested to hear otherwise. I can’t say I’ve missed it at all when moving from C++ to Java.

MatthewBot wrote up his thoughts on some language proposals, specifically named args, closures, and properties.

More info: BigDecimal operator support