It's a long way to San Francisco
My large frame does not like airline seats. At about 6 foot 8, my head towers over the back of the seat making the typical Iowa-to-Nevada nap most people enjoy on a cross-country flight like this impossible for me. Still, the hours of uninterrupted time (no phones, no email, no IM) means I can have a chance to catch up on what's new in the Java world. So, before getting on the airplane I thought I'd snag some materials from the Java Community Process web site and see what new nuggets were being considered for my favorite language. I could then read this nifty stuff in-flight.
I'm no Java futurist; I'm just a lowly Java user. Like many, I suspect, I just use Java to do cool things. Java has been one of my favorite languages since the version 1.02 days. It was small, lithe, and crafty with just the right number of gizmos to help me connect to the network and do other interesting things. Sure, there were holes in those early days, but I believed that the language designers would fill them as we went. Java's excellent beginning engendered a level of trust in that early programming community that those who led the language design effort would continue to do the right thing.
I didn't have a lot of time to prepare for my long cross-country journey and hoped I could quickly shlep all the relevant and interesting tidbits off the JCP site and on to my laptop for my in-flight entertainment. I first loaded the page listing all the JSRs and immediately noticed that the little elevator in the scroll bar was very, very tiny. How long was this page? How many JSRs are there?! I scrolled to the bottom and saw "925 JavaBeans Activation Framework 1.1". I Panicked. I scrolled up a bit. Ah, there was a break in the numbering. I saw there are only 277 JSRs. Two hundred and seventy seven?! I Panicked again.
Putting this number into perspective took me a few moments. Let's see: there are about 250 working days in a year (50 weeks times 5 days per week). So, if I were to spend only one day trying to understand each JSR, to grasp its intent and purpose, its vision, limitations, and promise, I would spend more than a year cranking through the list. Obviously that approach won't work.
I then began looking for ways to cut the list down to a manageable size. Some number of the JSRs were "withdrawn". OK, that happens: something sounded good in the beginning but, after some reflection, it wasn't such a good idea after all. About 43 fell into that category. About eight more were "rejected". That still left a large number to go through.
I thought, "I've got a fast internet connection. I'll just suck down the whole site and figure it out on the plane. I've got a handy-dandy little program that will traverse a web site and save it locally for offline viewing called Web Dumper by MAX Programming, LLC that should be perfect for a job like this. I'll use that."
Hmmm. It didn't work. It seems the JCP site isn't all that friendly to such a wholesale give me everything approach. Getting all the specifications and related materials is going to be a lot more tedious and time consuming than I had thought.
I began looking for a guide to answer basic questions I had in hopes it might further trim my list. Some questions immediately came to mind:
- Which of these JSRs apply to J2ME, J2SE, or J2EE?
- Which of these JSRs are just somebody's personal problem (a private package for, say, the tuna canning industry)?
- Which of these JSRs are going to actually produce artifacts that ship with every JVM of that flavor?
- Which of these JSRs produce changes (perhaps even incompatible changes) to existing JVMs and Java code?
- Which of these JSRs are already included in a release (and which release was their debut)?
Sadly, I couldn't find any such guide. I was thinking there would be a single table that held information like this in an easy-to-digest form. If it exists, I couldn't find it during by brief perusal of the web site. Does everybody just know this stuff?
Perhaps those well versed in this world can navigate through this puzzlement without effort but I found the experience to be a bit daunting. Plus, I couldn't stop thinking about the sheer number of proposals! I'm all for progress but can all of these things be important? There's a fine line between providing cutting-edge enhancements to a language system to keep it current, and simply junking it up.
I'm heading to JavaONE, the biggest Java nerd-fest on the planet. There will be some sessions that provide some introductions to particular JSRs. I've vowed to try to attend some of these but also acknowledge that these are likely to be as much a sales pitch as technical knowledge transfer events. What I'd really like to gauge is importance of the proposal and the commitment of those proposing it. My devious little mind then came up with a modern day crucible for testing such things.
JavaONE should have a whole section on the main floor dedicated to JSRs. Each JSR proposal team should have their own dunk tank to defend their proposal. For those who haven't frequented a carnival or charity event recently, a dunk tank is a small platform suspended over a large tub of icy water. A brave soul then sits precariously on the small platform while members of the public hurl balls at a small target. When a ball hits the target, the platform collapses and our unfortunate friend drops unceremoniously into the mirky deep.
My system would work thusly: say there was a JSR proposal 1013 "Adding the standard waffle iron interface package" to J2EE. I would make my way to the head of the line, be issued my first dozen balls, and begin interrogating the specification proponent.
"Tell me why this is important to Java's future!", I would shout.
The hapless specification writer would then grin and begin telling me of the importance of the waffle industry. Not moved by this I would continue.
"I know waffles are important. I happen to love waffles myself, but you're not answering the question!" I now feel obligated to hurl a few balls at the platform. My aim is bad. Mr. spec writer continues undeterred.
"Without a standard waffle iron interface, there'll be chaos in the small appliance interface community!", he'd say.
"And who, exactly, will that inconvenience? Maybe the small appliance interface community needs to mature a bit before we cast an interface in stone!" With my arm (and voice) warmed up, I begin hitting my stride -- and the target. Ker-splash!
Of course this is a bit fanciful. (You didn't want me to be grimly serious on my first blog, did you?) But, my points are clear and relevant (I hope). Proposing something that will affect the future of a programming language whose form will likely last longer than your career should be serious business. It isn't enough that some people will get in a room and say they are for something; to ensure you've really got a good and righteous thing you need to get people in the room who need to be convinced. I'm not advocating the inclusion of curmudgeons. I'm advocating the inclusions of skeptics.
The JCP is an open process. But, it must accommodate human nature, too. Most people don't want to be accused of just "raining on somebody's parade." So, using my whimsical waffleIronInterface example, there are probably lots of people who would say, "well, I don't understand the need, but I don't want to interfere with those who have worked hard on this. It must be important to somebody." If one group pushes, and skeptics aren't welcomed to provide a system of checks and balances, you can be sure you'll be seeing the waffleIronInterface (or something even more stupid) in a future version of Java.
Perhaps I should have gotten involved in the JCP sooner. My only alibi is I'm still running strong on the trust engendered by the original Java efforts. I watched the split of Java into J2ME, J2SE, and J2EE with some trepidation but ultimately deferred to the wisdom of the Java language leaders. I now wonder if the explosion of JSRs shouldn't be considered the herald's call to all lowly Java end-users like me to step up, at least a little, and see what's going on. Consider it a poster on the front door of the Java community: "Now hiring skeptics. Apply within."
All of this might sound more critical than I intend. And, admittedly, this is from the perspective of someone new to the game. But my efforts to fetch a little light reading for my trip made me wonder if some or all of these points are true:
- The Java Community Process might be a wondrous thing, but a little more organization of its content might help newcomers get up to speed more easily.
- Proposing something that is standard for users of the Java language is a serious business. While I believe standards and that the standardization process can be a powerful force, it can also be a stifling influence if not tempered with that sometimes elusive notion called common sense.
- The Java Community Process, with all its rigor, may provide a false sense of oversight. The process only ensures people go through the steps specified but cannot guarantee the quality of things approved. Only people in oversight roles can provide that.
- One of the best ways to force clarity in a situation is to drop an annoying, persistent, smart person in the mix who asks, "can you please explain that and provide your justification?"
I'll be walking the floor in Moscone, attending the talks, hanging at the BOFs, and generally having a good time this week. For those of you attending, I hope you'll take to heart my call for your involvement in the JCP. Attend a JSR-related session and ask the hard questions. Be that skeptic (a good natured one, to be sure) that helps bring clarity. We can talk about your successes by the dunk tanks.