I'm at Javapolis in Antwerp, Belgium, where I've given a keynote. It's Friday morning, and the day before, Josh Bloch gave a presentation comparing the issues in closures proposals. He sits across from me at breakfast and we further discuss the topic.

Since the beginning I've complained that, at the same time that it claims to be simple, Java is too noisy as a language. Code is read much more than it is written, and this noise directly translates to real costs in software development. Brain cycles are a very scarce resource, and anything that uses them up without benefit -- even something as seemingly innocuous as the extra verbiage in System.out.println() -- takes those cycles away from somewhere they could be useful, and reduces the programming efficiency of the language (Steve Yegge recently wrote about this problem).

In his presentation, Josh said that the last-minute addition of wildcards to Java generics may have pushed the complexity of the language too far. Neal Gafter has suggested that we reify generics. Both were originally unequivocal fans of Java generics, based on their responses to the criticisms I wrote about the topic. Now there seems to be a shift, and I've also seen other people begin to say "generics are still great but..." (Although Tim Bray recently called them a disaster).

The only control we have over complexity is abstraction: hide the parts that don't matter ("divide and conquer" is a variation). The paradox of Java is that a critical aspect of the complexity problem was ignored; code readability was not considered an important issue. It seems that if the IDE writes the code for you, then it doesn't matter if that code is needlessly complex.

Josh took this idea of complexity one step further. He said that it's not just the complexity of a particular feature in isolation, where it can often seem fairly straightforward. It's the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. When you shoehorn a feature into an existing language rather than carefully designing it in from the beginning, you cannot control how that feature combines with other existing features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it's too late to do anything about it. Over breakfast Josh noted that this kind of complexity makes for a bountiful supply of Java puzzlers; entertaining for him but not good for the community as a whole.

Map<Class<? extends Foo<?>>, List<Bar<? extends Foo<?>>>> map = new HashMap<Class<? extends Foo<?>>, List<Bar<? extends Foo<?>>>>();

/**
 * Special interface blah blah you stupid ninny
 * I did this to make your pitiful life simpler
 */
interface BarOfFoos extends Bar<? extends Foo<?>>> {
   ;  // this space intentionally left blank
}

public static interface Listener extends GenericEvent.Listener<FooEvent> {
      ;  // all done;
   }