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.

The beginning ... with Devoxx 2008

So this is finally going to be my first post on this blog. I've really put that off far too long and I'm hoping to turn this into a regular habit. Although it's been a few weeks since then, this year's Devoxx (fomerly known as JavaPolis, and Javoxx for a short time) gave me the final push over into the land of bloggers. I noticed quite a few people that were busy writing blogs at one time or another during the conference and met and recognized some because I follow their blog on a more or less regular basis. So the decision was made. I'm of course not the only one nor the first one doing this. If anybody's interested, the Devoxx web page contains links to dozens of blog posts about the conference. An especially detailed account of the first four days can be found here.

To begin with, the Devoxx conference is definitely the most exciting conference I've yet been to. 3200 attendees coming from 35 different countries. You get lots of interesting talks about lots of interesting topics as well as dedicated and knowledgable people all around. I find it nothing short of amazing that Stephan Janssen, the founder of Devoxx, manages to organize an event that costs about nothing compared to other conferences and yet has such an elusive list of speakers year after year. You could definitely call it Europe's JavaOne.

As I'm very interested in all kinds of programming languages and everything having to do with programming languages, I was glad to see that there were quite a lot of talks on that matter starting with a couple of 3-hour introductory university talks (all of them on the first day!) on Scala, JRuby, Groovy and Jython. During the main conference there were also a couple of more advanced talks on these languages. I especially liked Bill Venner's talk on The Feel of Scala where he dove a bit deeper into Scala's feature set and complexity. He mostly used his open source project ScalaTest as a running example to explain and show some of the functional benefits of Scala like currying and how he used them to "emulate" Ruby's RSpec in certain aspects. Other parts of his talk were dedicated to aspects of Scala's sophisticated type system, e.g. structural types, views, etc. Quick side note: As you may probably know, the first book about Scala, Programming in Scala (by Martin Odersky, Lex Spoon and Bill Venners), was released just a few weeks ago and apparently was the best-selling book at the Devoxx book store.

Well, Devoxx is still mainly a Java conference and thus one of my personal highlights was that we were finally provided with some first-hand news about Java 7 and, hold your breath, a release date, early 2010, in Mark Reinhold's keynote (note, however, that he described his presentation as being not binding). After Joe Darcy already blogged about a JSR for small language changes the day Devoxx started, Mark also talked about Sun's plans for Java 7, including some more or less likely features and language changes in Java 7 as well as the controversial topic of Java modularity in the form of Project Jigsaw. He even suggested that Jigsaw could provide the basis for breaking backwards compatibility with older JDKs and could help to get rid of the classpath (hell) as we know it. I'm not exactly sure how introducing modularization into the JDK/JVM would help to achieve those ends, so I'm gonna have do some research on that. Another interesting take-away from the keynote was the clear statement about which language features won't make it into Java 7: Closures, first-class properties, reified generics, etc. to name just a few. I won't go into any detail here because other people have already written about that at great length, e.g. Hamlet D'Arcy compiled a complete list of the stuff Mark talked about.

Even though I don't feel qualified enough to really comment about Project Jigsaw, I was left with the impression during a BOF session with Mark and Alex Buckley that Sun itself is not yet very clear about Jigsaw and modularizing the JDK/JVM. There were more than a few questions that were answered with a neutral "Yeah, we still have to figure that one out", e.g. when it comes to the interaction of modules and the protected keyword. Apart from that, the BOF turned out to be quite interesting (even though 90% of the time was spent talking about Jigsaw). For example, as you would expect, the question about reified generics was also raised and Alex argued unsurprisingly against introducing them in the JVM. Basically, the question he asked was: What do they really bring you apart from being able to reflect over the type at runtime? You'd still be not able to call new T() in Java as that's inherently not possible without introducing structural types. Furthermore, you would considerably complicate the use of libraries because you'd have old code without generics, new code with erased generics and on top of that new code with reified generics. Sounds like an awful mess! According to Alex, this whole issue of reified generics is apperently just to complex to shove into the JVM.

For me, the most intersting talk of the conference was Towards a Dynamic VM by Alex Buckley and Brian Goetz. They spoke about JSR 292 (Support of Dynamically Typed Languages on the JVM) at great length and did a terrific job at presenting a reasonably complicated and deeply technical topic in a quite accessible way. It included facts about method handles, interface injection and, of course, the invokedynamic bytecode. For anyone who's interested, the early draft of the spec goes down pretty well and is very informative. Charles Nutter also has a great article about JSR 292. Funny thing: Mark Reinhold mentioned during his keynote that there won't be an invokedynamic instruction, but Alex and Brian said that there would only an hour later. It turned out that Mark based this section of his talk on slightly outdated information. He said that John Rose, the spec lead of JSR 292, "reintroduced" the bytecode instruction only a couple of weeks ago.

I'll spare you the probably boring recollections of each and every talk I've attended, so here's a list of just a couple of more highlights:

• Josh Bloch keynoted about the second edition of Effective Java. Unfortunately, it was almost exactly the same talk he gave at JavaOne earlier this year. I've not been there, but I've watched his presentation on the Sun Developer Network. Although I've not heard anything new, I find Josh's style of presentation highly entertaining.
  
• Brian Goetz talked about library-based parallelism in Java 7, e.g. the fork/join framework. As I've read his book on Java concurrency from front to back (highly recommended!), it was cool to see him talk in person. He really knows his stuff and provided an interesting overview of possible additions to the java.util.concurrent library for Java 7.
• Mahmood Ali gave a talk about pluggable type-checking with JSR 308 (Annotations on Java Types). Mahmood, member of the expert group, did a very good job in showing the use of so-called type checkers. By allowing Java annotations to appear in more places in the source code, you're able to write more informative types (i.e. "extending" the type system) that can then be detected by type checkers. I'd have wished for a bit more in-depth presentation and Mahmood also finished about 30 minutes short, but it was a good talk nevertheless.
• As always, the live recording of the JavaPosse was just pure fun; not just because Atlassian gave out free beer again (cheers!).

Again, the general discussions that were held on the obligatory whiteboards on the first floor attracted a lot of attention this year. Photographs of all of them can be viewed here; compiled results are available on Stephen Colebourne's blog. Two of the whiteboards invited all attendees to vote for or against particular language features for Java 7. Stephen Colebourne meticulously compiled these results as well (great work, Stephen!). Josh Bloch, Alex Buckley and Brian Goetz were often seen hanging around there having discussions with people about one thing or another and/or answering questions.

Well, nothing ain't perfect. One of Devoxx's biggest downsides was that internet access was very slow and unreliable. Apparently the conference's provider made some mistakes and they ended up with only a couple of 1 MBit lines. Obviously not good enough for 3200 people almost constantly browsing with their notebooks and iPhones and downloading stuff and tools they've seen during the presentations. Well, it got a bit better towards the end of the week, but it was nevertheless still far from being usable. A co-worker of mine tried to download the latest version of Scala on Monday, but failed until Thursday night. Well, it'd be cool to check out some of the stuff you've seen right away, don't you think?

As a minor point I would have wished for a bit more variety in meals. They gave out sandwiches on Monday and Wednesday and a bowl of salad on Tuesday and Thursday. No vegetarian food. But lucky enough, the Metropolis complex in Antwerp houses a couple of fast food restaurants.

Above downsides notwithstanding, my overall experience at the Devoxx conference was very satisfying. I was able to learn a few new things and was given the chance to catch up on some stuff that I promised myself to study for some time now. There was a lot more to Devoxx than just what I've written about, but I've restricted myself to a few personal highlights. As you probably may have noticed, I didn't mention JavaFX at all, which was released just a couple of days before Devoxx started and thus had its launch party at Devoxx. Well, I've just not yet caught up on the "hype"...