Dark Views

If you ever wanted to know if it is possible to go through 60 information-packed slides in 50 minutes: Yes, it is. I’ve been there and Joshua pulled it off in from of about 100 people, so it’s not a delusion of mine, either.

In his talk, Joshua presented a host of reasons why the BGGA proposal is a really bad idea. The key information here is “BGGA”. We all want closures and Joshua is no exception, it’s just that the BGGA proposal is like Generics on steroids and if you can’t wrap your brain about Generics wildcards, then you won’t understand BGGA closures as well.

The code in the proposal doesn’t look too bad at first glance:

{int x, int y => x+y}

Unless you try to use an array. If you did “int[] x”, you’d get an error because closures are based on generics and generics can’t handle arrays or primitives.

But the next example is better to understand why BGGA will add a new level of hell to Java which will be worse than generics:

{int,String=>Number throws IOException} xyzzy;

is translated into

interface Function1 { // system-generated
    R invoke(int x1, A2 x2) throws E;
}
Function1 xyzzy;

Doesn’t bother you because you’re never going to see this? Well, think again because if you try something that the generics type system doesn’t understand, you’ll get a generics error message like this one:

NewtonWithClosures.java:26: invoke(capture#418 of ? super {double => double}) in {capture#418 of ? super {double => double} => capture#928 of ? extends {double => double}} cannot be applied to (double)

The reason for this is that the closures are implemented using generics and without any high level support in the compiler so the compiler can’t generate a more useful error message. And this was a simple example. We all know how quickly generics get messy and for me, that means that any implementation of any new feature that is based on generics is a threat to the future of Java.

Again, I’m for closures and I use them as often as I can in Groovy but the current proposal is just a new way to make Java harder to use. Why don’t they simply change the compiler to allow to access field and method objects (from java.lang.reflect) via the class? Like so:

collect(list, Math.class.min)

If we could use Method objects like first class citizens (instead of via the horrible reflection API with it’s horde of checked exceptions), we could use Method objects as simple closures. Then, all we would need is a set of util classes for single mutable primitives and we’re done. Sure, the syntax wouldn’t be as compact but every normal Java developer would be able to understand the concept and how it’s supposed to be applied in a few hours.

If you care, here is a link to the whole set of arguments by Joshua Bloch. Read it, keeping in mind that Joshua is pro closure, he just wants to avoid a second generics debacle.

I wish I could link that presentation because it was the best I’ve seen in the whole show, both visually and how it was presented. So here is the link to the abstract. There is something to be learned by this talk for anyone who wants to demo a software: One human being can’t talk and use a computer at the same time. While David explained things, Bertrand wrote the code. Thumbs up!

And in this case, the visual candy didn’t distract from the fact that these guys were really showing off something that ought to have an impact. They showed agile web development with Apache Sling.

A sling gives you range and power and Apache Sling does just that. With just a few pieces of JavaScript added to an existing static HTML web site, they built a blog in roughly 10 minutes. Impressive. I’ve got to try this out myself, probably this weekend.