Part IV, Finalizing a Java Specification Request
Some processes are like breaking an egg, with a clear linear sequence that includes an overt beginning, a messy middle, and an indisputable end. For a Spec Lead operating within the Java Community Process (JCP) program, the process of developing a Java Specification Request (JSR) is more like a looping roller coaster, with upward climbs, nearly stalled plateaus, and exhilarating downward sprints, having no end in sight. It's possible for the momentum to stop, but just because a JSR goes final doesn't mean it actually will stop.
The "final" leg of the JSR process involves production of a Proposed Final Draft (PFD), the Final Draft Submission, the Final Approval Ballot vote by the Executive Committee (EC), and the Final Release. But then there's the endless trickle of comments, suggestions, and requests for new features that can keep a Spec Lead busy in perpetuity.
After the EC approves a draft of the specification during the Public Draft stage, the Expert Group concludes work on the various pieces of the JSR and comes up with the PFD.
David Nuescheler, the chief technology officer (CTO) of Day Software, is the Star Spec Lead for JSR 170, Content Repository for Java Technology API, and JSR 283, Content Repository for Java Technology API Version 2.0.
David believes a JSR is ready to be considered a PFD when it has no outstanding issues. The primary components of the Final Draft Submission include the specification, the Reference Implementation (RI), the at-least-mostly-completed Technology Compatibility Kit (TCK), as well as the licensing terms for those three parts. David recommends that the submission also include the java source, javadoc, and a compiled .jar (Java ARchive) file.
He says, "A good testing effort for the PFD package is even more important than during other stages since small issues usually pop up due to the continued RI and TCK development. Hopefully nothing major is discovered at this point, though."
In serving as Star Spec Lead for the Java Data Mining (JDM) standard, versions 1.0 and 2.0 (JSR 73, JSR 247), Mark Hornick represents Oracle Corporation, where he is currently the senior manager in the Data Mining Technologies group.
According to Mark, Spec Leads know it's time to submit the final draft of the JSR for the EC's Final Approval Ballot when the TCK and RI are essentially complete, the RI passes the TCK, most of the bugs have been "shaken out of the specification," and there are no remaining issues raised by the EC or the Java community for the Expert Group to resolve.
"Polling the Expert Group should give you a good indication" of readiness, David adds.
When the Expert Group submits the Final Draft, the PFD is posted on the jcp.org web site for the specific JSR, and the EC has fourteen days to vote on the Final Approval Ballot. The Expert Group can request specific outside individuals to review the specification, wait for comments from the community at large, or both. Mark notes that the PFD often reveals gaps in the specification, RI, TCK, and javadoc. He says, "It's a dry run for the Final Release." While it's important to address these missing pieces before the Final Release, there can also be a need for triage.
Mark explains his priorities for revision during this stage, saying, "Minor corrections to the specification such as javadoc typos or unclear wording can be easily addressed. Other issues such as modifying data types for return values or parameters, or adding or dropping a method will only be accommodated if the specification would be faulty otherwise. Features requiring multiple methods or new interfaces are deferred to the Maintenance Release or a new JSR. New features need to be deferred to allow the existing feature set to see the light of day".
Danny Coward is the Java Standard Edition (Java SE) platform lead at Sun Microsystems. Within the JCP program, he is a Star Spec Lead for JSR 53, Java Servlet 2.3 and JavaServer Pages 1.2 Specifications; JSR 124, Java EE Client Provisioning Specification
; JSR 154, Java Servlet 2.4 Specification; JSR 175, A Metadata Facility for the Java Programming Language; and JSR 308, Annotations on Java Types. Danny says the most important way to receive yes votes on the Final Approval Ballot is to "make sure your Expert Group is enthusiastic and fully behind the spec."
According to David, members of the EC use their individual connections with the Expert Group to decide on their vote. To lay a foundation for success, David also tries to communicate with the EC and be open to their input. "Generally, I would like to recommend that a Spec Lead be open and consider anybody's input, not just the EC's.
I always tried to preemptively find out if there was anything that needed addressing from an EC perspective by sending out an email to the EC well in advance of any vote. My interaction with the EC has always been very positive and very limited. Throughout the process, I was close enough to the EC to be aware of the issues, so there was never an element of surprise."
In this final stage of the process, David has noticed that the EC focuses more on the business terms. For example, the only comments the EC offered David during this stage related to support for his open source licensing model.
Danny agrees that at this late stage, the EC often has very little to say directly to the Spec Lead. In contrast, during an earlier draft stage, Danny was once surprised to get a fax from an EC member who had red lined all the editorial and grammatical mistakes in the spec.
Besides being a veteran Spec Lead, Danny also serves as Sun's primary representative on the SE/EE (Enterprise Edition) EC. He unveils some of the EC's behind-the-scenes protocols: "The EC's role at voting is generally to ensure that the JSR is progressing according to its stated plan, that the Expert Group is functioning well, and that the Spec Lead is doing a good job of balancing the needs of all the Expert Group members. JSRs that have had problems at ballot often have some problem going on in the Expert Group."
EC members tend to be highly active in JSR development. Therefore, a Spec Lead's company is often represented on the EC. Often, the EC representatives will represent their Spec Lead for a JSR if there are questions or issues. Danny says, "I think companies who have EC representation can get a smoother ride compared with companies who are new to the process, in cases where there are bumps, because they have the experience of having seen other JSRs being voted on, and they also may have more familiarity with other EC members."
However, Danny doesn't see any Spec Leads getting left behind. "In general if there are issues, the EC works hard to make sure it is representing the whole community, including the Spec Lead of the JSR, whether or not they are on the EC, and whether or not they work for the same company."
To vet a JSR before a vote, EC members typically read the spec and make sure it does what the JSR set out to do. If they have a representative on the Expert Group, they may check with them to discover how things are going. They also review the RI, TCK, and associated licenses that the Spec Lead makes them available under. They may even look atthe RI and examine the TCK in detail to make sure they are of a good quality, says Danny.
After the EC approves the JSR as final, there is not much left to do for the final release. David says, "It's just a bit of an administrative thing, to get all the pieces aligned." For JSR 73, Mark's team provided a zip file of the specification, javadoc, RI and TCK, XML Schema, and Web Services specification to the PMO for posting on the jcp.org web site.
Some Spec Leads might offer a ceremonial closure for the Expert Group, but neither David nor Danny did. "I think active standards live beyond a single JSR, so as our closure we filed the next JSR together," says David.
Mark's group enjoyed a celebration of sorts. For JSR 73 (JDM 1.0), they held their "final" face-to-face meeting simultaneously with the kickoff of JSR 247 (JDM 2.0). Mark says, "One evening during this multi-day meeting, we had a celebration in Boston for the JSR 73 Expert Group members. It started at the Museum of Science and ended on the Spirit of Boston," a ship that cruises from the Boston Harbor.
After final release, a Spec Lead still has work to do. Mark's view is that "It's inevitable that a Maintenance Release in not far around the corner. Sifting through leftover requirements and bugs that invariably turn up, decisions need to be made about what goes into the Maintenance Release and what goes into the next JSR."
Close to the top of his to do list, Danny says, is "worry about the next version! And of course be ready for feedback on the quality of the spec, RI, and TCK that were just completed."
Feedback drifts in, often related to items that need fixed in the specification. A Spec Lead's hope is that these issues will be simple typos or small ambiguities that can be handled in a maintenance release rather than postponed until the next full version.
"Keep in mind that the 'final' in PFD does not mean this is the end of days", David cautions. A follow-up JSR is usually filed reasonably shortly after the final approval to continue development of the standard. "I still look at all the e-mails and monitor the activity around JSR 170. Obviously, I tried to move most of our efforts to JSR 283 and continue development there", says David. "Being a Spec Lead is a life sentence."
It's not uncommon to recognize problems with the final RI or TCK, Danny knows. For instance, an RI can have bugs or behaviors that do not conform to the specification. A TCK can have tests that are missing, and sometimes tests that mistakenly assess things not in the specification, or tests that turn out to be ambiguous in some unexpected circumstance. Such issues are more common when a TCK is run against a product for the first time, and the Spec Lead has to deal with them.
People also continue to submit feature suggestions even after the final JSR is published. David's preferred strategy is to defer these until the next version of the specification.
Thus, the work of a JSR goes on and on, "Never done!" as Danny says.
Back to part 3...
Go to part 5...
|
