Does size matter?

After years of discussion, countless debates, musings, polls and seemingly gazillion proposals (see Alex Miller's awesome Java 7 feed / page), it seems there's hope after all. Recent events indicate that concrete plans for Java 7 are finally under way:

• Joe Darcy recently "proposed an OpenJDK project to host the discussion of the proposals and potentially some prototype implementations" of a set of small language changes in Java 7.
  
• Only one day later, the majority of members of the OpenJDK Compiler Group "ratified" the proposal.
  
• That same week Mark Reinhold keynoted about Java 7 at the Devoxx conference, Antwerp, and even announced a preliminary release date: early 2010

And it's about time. It's been over 2 years since Java 6 came out and it will be just over 3 years if the release date proves to be accurate.

However, there's that word ... small. Sun is dedicated to keep any changes to the language small, at least for the coming release. As Joe Darcy put it:

"Given the rough timeline for JDK 7 and other on-going efforts to change the language, such as modules and annotations on types, only a limited number of small changes can be considered... ."

But, what is small, anyway? Joe Darcy offers his guidance on measuring the size of a language change, which is definitely an interesting read. Here, a language change is defined as small if it is about equally small under all three mandatory deliverables of a JSR, namely Specification, Reference Implementation and Compatibility Tests. (Additionally, a small language change may be distinguished by likely requiring little effort to learn the involved concepts). Joe also gives a few examples: in order to measure the size of a specification change, one has to assess several factors, e.g. the number of new concepts, their complexity as well as their interaction with existing features and elements of the language, which, in turn, may result in more changes to the specification. For example, autoboxing / unboxing is an example where the concept itself seems quite simple, but the actual complexity stems from interaction with generics and method resolution. Thus, autoboxing / unboxing has to be considered a medium-sized change. As Joe wrote before, changing the Java language is not such a simple deed after all. Interestingly, Alex Buckley tackled this issue once by arguing that the complexity of a language feature could be measured by exploiting the structure of the JLS in that one analyzes which parts would be affected by a given change. Subsequently, the complexity is calculated according to a formula that involves, among other things, cross references between chapters that need to be changed to fully describe the feature. Intersting, indeed.

A consequence of considering only small changes to the language is, of course, that some of the most hotly debated topics in the community, e.g. closures, first-class properties and reified generics, won't make it into Java 7. This was more or less confirmed in Mark Reinhold's keynote at Devoxx. In general, Joe Darcy suggests that changes to the type system are probably out of scope for Java 7 as they entail at least a medium-sized change. The community didn't take long to react ... mostly with disappointment as it seems.

Well, now we've got this out of the way, the next obviuos question is: which language changes are going to be in Java 7, that is, which ones are deemed small enough to be considered for addition? As we all know there's a plethora of things that people like to see added to the language and I don't dare try to list each and every one of them (Alex Miller's aforementioned page is a good start, though). Apparently one of Sun's primary goals for the coming release is to identify and adress the average Java programmer's day-to-day pain points, that is, common coding patterns that have been recognized as needlessly verbose. Some of the most recent attempts to measure the pulse of the community in this regard were undertaken by Stephen Colebourne (this year's results are available here and here) as well as by a friend of mine, David Linsin (here). Stephen's presentation outlines some of the proposed changes. Note, however, that most of those and other proposals (if not all of them) have been around for years in Sun's bug databases and have surely been discussed equally long. Some have also been prototyped and provided on kijaro, if you're interested.

Ok, so what do I think? As a matter of fact, I think, yes, size does matter and I'm more or less happy with the current course of events. I agree with Alex Buckley when he said that:

"The tough part isn't designing any single one of [those hundreds and hundreds of possible features in the database] ... but choosing which ones to design. We have to Do The Right Thing as well as Do The Thing Right."

Judging from all those polls the majority of developers desparately craved for having closures in the language (or reified generics, first-class properties, etc. for that matter, depending on who you talk to) even though we've not been able to reach a consensus on which form they should have taken eventually (or even at all). Some even predict Java's death now that the decision's been made. They fear, and mostly seem quite certain about it, that Java's demise is just a matter of time in the face of all the other languages that offer all those shiny constructs. While I don't agree with Ricky on that particular matter, I personally would have loved to have closures in the language for the benefits they bring: more concise and expressive code (compared to anonymous inner classes), the ability to create control abstractions for recurring patterns, etc. Not to mention that full closures would render the discussion about automatic resource management (see also in the presentation above) and probably a couple of other proposed language changes obsolete. Furthermore, they could simplify existing or proposed Java APIs like Doug Lea's Fork/Join framework, which is part of JSR 166y (the API/source code of a port to the BGGA prototype is available here).

However, inspite of the (overwhelming?) advantages of supporting full closures in Java, I'm primarily concerned that above polls are not a representative cross section of the world-wide Java "community". Mind you, I'm basing this solely on my personal experience so far. Most of the developers I know for example don't have the slightest idea what a closure is and what is is good for in the practical sense let alone the technical sense (I'm talking Java developers here). Most of them don't even know that there've been attempts to add closures to Java for years now. Mentioning it gives me mostly blank stares or irritating "why-don't-you-occupy-yourself-with-something-reasonable" laughs even from seasoned developers. Let's face it, a lot of developers concern themselves with the stuff they are paid for, but don't care about anything beyond. Taking into consideration that generics have been around for close to 5 years now and that most people (again, based on my experience) don't know how to use them correctly (*), I think closures would add another level of complexity to the language that most developers wouldn't know how to deal with correctly, especially when combined with generics etc. I imagine that such code would be hard to read, hard to write and very confusing to most of them. Even though I fooled around with the BGGA prototype quite a bit and know what closures are about in general, I'm not so presumptuous to exclude myself from that group completely. I really liked Josh Bloch's presentation at JavaPolis 2007 on that subject. As Brian Goetz said:

"The issue being debated is not whether closures are a good idea -- because they clearly are -- but whether the benefits of retrofitting the Java language with closures are worth the costs."

Personally, I think that it's not worth it for the reasons above. At least now. As I've already said, I'd be quite happy with some of the current proposals for small language changes because they'd indeed make my daily life a bit easier, e.g. improved type inference on the declaration of parameterized types, catching multiple exception types and List/Map literals. Some of them (e.g. null de-referencing), I hope, we won't ever see added to Java, but that's left for another day. At Devoxx I listened to Thomas Enebo's and Charles Nutter's talk about JRuby and I was sometimes simply amazed at Ruby's conciseness and expressiveness compared to Java and its capabilities in general (Scala's another candidate here). Since then I wished Java could do the same on more than a couple of occasions. Perhaps "features" like List/Map literals can bring a tiny bit of that feeling to Java.

To conclude, I'd find it interesting to apply Joe Darcy's aforementioned sizing criteria to the currently proposed changes. I don't feel qualified enough to do it myself, but I hope somebody will sometimes.

* That's a bit unfair though, I guess, because I doubt that there are a lot of people in the world that may claim to know everything about generics and how to use them without growing a foot-long nose.

Update: Just stumbled across Alex Miller's article on JavaWorld where he muses about expected additions and changes for Java 7.