ON THIS PAGE
    ARCHIVES
    CATEGORIES
    BLOGROLL
    LINKS
    SEARCH
    MY BOOKS
    DISCLAIMER
 
 Monday, February 18, 2008
Who herds the cats?

Recently I've been looking more closely at the various (count them, four of them) proposals for adding new features into the Java language, the "BGGA", "FCM", "CICE" and "JCA" proposals. All of them are interesting and have their merits. A few other proposals for Java 7 have emerged as well, such as extension methods, enhancements to switch, the so-called "multi-catch" enhancement to exceptions, properties, better null support, and some syntax to support lists and maps natively. All of them intriguing ideas, and highly subject to reasonable debate among reasonable people. My concern lies in a different direction.

Who herds this bunch of cats?

This isn't just a question of process within the JCP. And it's not just a question of closures or the other features we're looking at for Java 7. This is a question about the moral leadership of Java.

In the C# space, we have Anders. He clearly "owns" language, and acts as the benevolent dictator. Nothing goes into "his" language without his explicit and expressed OK. Other languages have similar personages in similar roles. Python has Guido. Perl has Larry. C++ has Bjarne. Ruby has Matz. Certainly other individuals "float" around these languages and lend their impressive weight towards the language's design--Scott Meyers, and Herb Sutter in C++, for example, or Dave Thomas and Martin Fowler in Ruby--but the core language design principles rest firmly inside the head of one man.

Whereso for Java? James Gosling? Please--Jimmy abandoned the language shortly after its release, and now only comes out every so often to launch T-shirts into the crowd, answer reporters' questions whenever something Java-related comes up, and blog his two cents' worth. He's a reminder of the "good old days", for sure, but he's not coming out with new directions of his own accord and taking the reins to lead us there. He's the Teddy Kennedy of the Java Party. His endorsement weighs in as about as influential as Bob Dole's--interesting to an analytical few, but hardly meaningful in the grand scheme of things.

Unfortunately, the two most recognized "benevolent dictators" of the Java language, Neal Gafter and Joshua Bloch, are on opposing sides of the aisle on this. Each has put forth a competing proposal for how the Java language should evolve. Each has his good reasons for how he wants to implement closures in Java. Each has his impressive list of names supporting him. It's Clinton and Obama, Java Edition. The fact is, though, that when these two disagreed on how to move forward, lots of Java developers found themselves in the uncomfortable position faced by the children when the parents fight: do you take sides? Do you try to make peace between them? Or do you just go hide your head under a pillow until the yelling stops?

This is the real danger facing Java right now: there is no one with enough moral capital and credibility in the Java space to make this call. We can take polls and votes and strawman proposals until the cows come home, but language design by committee has generally not worked well in the past. If someone without that authority ends up making the decision, it will alienate half the Java community regardless of which way the decision goes. The split is too even to expect one to come out as the obvious front-runner. And expecting a JSR committee process to somehow resolve the differences between these four proposals into a single direction forward is asking a lot.

So who makes the call?


Monday, February 18, 2008 10:40:29 PM (Pacific Standard Time, UTC-08:00)
As with all sufficiently polarizing decisions, it is important to at least consider alternative - make no decision. Closures are certainly powerful and there is no doubt Java could benefit from them, but is the benefit worth the polarization of the community?

I guess it comes down to the amount of polarization we are talking about. Are we talking about a mass Java exodus from the "losing" camp, or just a few angry blog posts?

Either way, this is a crucial time for Java. Many people are already investigating other languages, especially those that run on the JVM like Scala, Groovy, JRuby, etc. With these kinds of options, perhaps we can get away with depriving Java of closures.
Tuesday, February 19, 2008 4:54:28 AM (Pacific Standard Time, UTC-08:00)
Totally agree. We see this problem (design by committee) manifest itself in a great many ways in Java, from overlapping JSR's to incompatible component models. The fact that 40% want full (BGGA) closures and 40% want nothing to do with them suggests the community is already greatly polarized over the vision of Java. While Moore's law has been kind to Java, the clutter of continual patching up without braking compatibility has not been particular kind to the developer using Java.
Casper Bang
Tuesday, February 19, 2008 9:39:38 AM (Pacific Standard Time, UTC-08:00)
This is why Sun must take back Java. Screw JCP and other opinions. It was a mistake to let the cow out of the barn.
God
Tuesday, February 19, 2008 12:04:09 PM (Pacific Standard Time, UTC-08:00)
but language design by committee has generally not worked well in the past.
Note none of these languages were really designed by committee: C, C++, Javascript. By the time they got to committee, the languages already existed, and even as the committees added features, those features were almost always already designed, implemented, and in real use by the time the committee put a rubber stamp on them.

The only language I can think of that might really be considered "designed by committee" would be ADA.

Presumably, you more precisely mean "design by consensus among a large group across various organizations". That hasn't happened, either.

I don't necessarily think that "design by consensus" (e.g. the JCP) will work well either. I just want to dispel the inaccurate picture of standards bodies (like C and C++) designing new features by getting views and consensus from a wide audience. That never happened.
Andy Tripp
Tuesday, February 19, 2008 1:05:22 PM (Pacific Standard Time, UTC-08:00)
Making no decision will not avoid polarization, nor will it prevent some users from leaving the Java camp for apparently greener pastures. After all some have already gone. The only benefit of "no decision" is that it is easily reversed, but it is also the least satisfying decision for all concerned.
Mark Thornton
Tuesday, February 19, 2008 2:24:43 PM (Pacific Standard Time, UTC-08:00)
Maybe Java should split into different languages!!
Mike Gale
Tuesday, February 19, 2008 4:36:57 PM (Pacific Standard Time, UTC-08:00)
"Maybe Java should split into different languages!!" - Mike Gale

Yeah, we could call them Java 6 and Java 7!

I heard someone suggest that Scala should just be renamed to Java 8.

Seriously, though, I think I see your point if you mean that perhaps Java 7 should forget about backward compatibility. That's the thing that is responsible for language bloat in the first place.
Wednesday, February 20, 2008 8:35:45 AM (Pacific Standard Time, UTC-08:00)
I think the "Benevolent Dictator" issue is a red herring.

The real tensions are between a) compatibility and b) evolution. There are three solutions:

1) Fossilization. Say "no" to new features. You have perfect compatibility, your head never hurts from having to learn something new. But the language occupies a smaller and smaller niche, as people find it too unproductive in comparison with all the shiny new languages. Example: C. The bash shell.

2) Incompatible evolution. Periodically add new features, clean up the cruft, tell people to suck it up and rewrite their code every few years. Example: Python. Perl. PHP.

3) Compatible evolution. Add new features, but keep them backwards compatible. Messy, messy, messy, but incredibly successful in the marketplace because people don't really want to throw away their old code. Of course, eventually things break so badly that most people bail. Example: C++. Java.

Maybe 2) can only be done with a benevolent dictator. If you want that, don't choose Java. Java hasn't had a benevolent dictator for over ten years, and it won't get one. The reality is that Java is ultimately driven by the perceived need of large corporations, first through Sun licensees, now through the JCP. They want backwards compatibility, and they also want evolution.
Wednesday, February 20, 2008 10:02:59 AM (Pacific Standard Time, UTC-08:00)
Cay,
The scent of sarcasm is a bit too pungent in your preceding post.

"Java is ultimately driven by the perceived need of large corporations..." (??)
Absolutely not solely, and, if in part, so what? There is no ulterior motive or covert conspiracy theory in marketing a programming language to address the needs of business. Without the needs (whether perceived or established via altruistic cognition) of the business domains, what need is there for a programming language?

"...eventually things break so badly that most people bail. Example: C++. Java." (??)
You're suggesting that most people are bailing off the Java bus? Man, that's hype. And you're coupling Java with C++ at this point? In so many ways that is absolute hype. In the last few years I've coded mobile solutions using Java ME that were deployed to an array of different mobile devices, enterprise solutions for medium and large companies using J2EE technologies and Spring, and worked with Swing on an application deployed via JNLP to a specific set of users. And before anyone picks at the shortcomings of any one of these scenarios, since none are perfect, consider what is common among them: the Java programming language serving business needs again and again.

I respect your opinion Cay, but if I find out you're working on a Scala book you want to outsell your Java books... well, that's what I would call an ulterior motive;-) And I do have a couple of your books on the shelf at home... good work. And good evidence of an applicable programming language standing the test of time.
Evan J. Goff
Wednesday, February 20, 2008 1:13:26 PM (Pacific Standard Time, UTC-08:00)
Tell me, the proverbial man on the street, the average programmer, what reasons do I have to trust benevolent dictator Gafter or benevolent dictator Bloch?

Judging by the recklessness with which they put forward their closure proposals, making it a personal issue, I have to conclude that they have long lost touch with the people. "Moral capital"? They lost most of it in the generics debacle, where a loud and clear "Stop that s...!" from a really benevolent dictator would have gone a long way. I am still waiting for an apology for generics and a clearly laid out plan how to fix them. Oh, wait, they are to busy to fight for closures instead of taking care of real language issues.

There are not only the big issues like closures or generics. There are small issues and details that are neglected and need attention. What distinguishes the C#, Python, Perl, C++, Ruby leaders from the Java leaders? The first group cares about even the smallest detail of their language. Cares about bugs, and cares about the users. The Java leaders? They care about their egos, their next book deals and career steps. "Credibility"? Pah!

Will I just hide my head under a pillow until the yelling stops? Oh yes. What else could I do?
Stefan Horet
Wednesday, February 20, 2008 2:00:49 PM (Pacific Standard Time, UTC-08:00)
Stefan, the generics proposals were developed in public over a number of years. Did you have your head under the pillow then too? If so, you deserve no apology and should share the blame for the defects.
Mark Thornton
Wednesday, February 20, 2008 8:57:26 PM (Pacific Standard Time, UTC-08:00)
I have to agree somewhat with Stefan. I couldn't believe it when I heard at JavaPolis from both Gafter and Bloch how properties are bad because they clashes with correctness. As Cay Horstmann has blogged about, indeed properties gets no respect. Never mind the fact that they currently exists through clunky introspection schemes and naming patterns at an important abstraction/architectural/component level and is essential for any WYSIWYG design tool to function... yet they seem to have been dismissed because they aren't interesting in regard to fork-join frameworks.

Allow me to add another possibility to Cay's list:

4) Fork and fix Java while maintaining a legacy version. Move the art forward by means of a compatibility layer and code migration tools.

Do it right or don't do it at all - everything else is just pushing the problem ahead until the accumulated puzzlers cause a meltdown. So if things seem bad now, imagine the next go round of "compatible evolution".

@Mark We can't all be language designers yet most can recognize when something just ain't right. I.e. I am no mechanic, but I am able to tell when my car need a checkup.
Casper Bang
Thursday, February 21, 2008 12:54:26 PM (Pacific Standard Time, UTC-08:00)
Mark, you are trying to convert victims into culprits. I take no blame for being one of the millions the generics makers managed to fool.

Indeed, the generics makers formally did it in the open. With what, five document releases in five years? They managed to hide their mess very well in these documents. E.g., in the big fat language specification. Instead of publishing deltas, they just published an altered 400+ page release of the language spec. If you are a full time employee, not being paid for monitoring the JCP, you just don't have the time to check such a document to figure out all the fine details and implications.

Like millions I was so stupid to trust the Java makers that they knew what they were doing with generics. This trust was massively abused. For this trust abuse alone millions of Java programmers deserve an apology.

Unfortunately, the Java leaders haven't learned. They tried the same trick with closures. But this time people were alert. Fool me once, your bad. Fool me twice ... With closures it becomes more obvious that generics weren't an accident, but a result of system inherent flaws. One such flaw are the egos of the decision makers, who are more busy to make a name for themselves than caring about the language. I could write a long list of issues in Java that hurt programmers. Leaders who care would have addressed many of them a long time ago on their own initiative. But nothing happens, because "our" leaders don't care and don't listen.

So, please hand me my pillow so I can hide my head under it. I don't want to hear it any more, I can't stand watching it any more.
Stefan Horet
Thursday, February 21, 2008 8:56:17 PM (Pacific Standard Time, UTC-08:00)
FYI, we are working on improving generics, for example: reification, significantly improved diagnostics for wildcards, and improved type inference. It can't all happen in JDK7 due to time and resources, but the issues are not being ignored.
Comments are closed.