About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
Part VI, Maintaining a JSR
Part of the allure of participating in the JCP program comes from the opportunity to produce something new and useful. Something that may enhance the cell phone you can show off to your girlfriend or neighbor. Something that may revolutionize the Web again. It's a challenge worthy of exciting Star Trek music to go where no one has gone before.
And then there's maintenance. In the heat of looking ahead and meeting deadlines and getting to market as soon as possibly possible, the maintenance phase of a JSR is often overlooked. However, when considering the good of the technology long-term, this phase is more important than one might think. Work continues: collecting ideas for future enhancements, identifying issues to resolve and bugs or typos to fix, and assessing any demands for a new or better test or implementation.
As soon as a JSR posts its final release of the specification, RI, and TCK, the Expert Group disbands, and the JSR goes into a maintenance phase. A Maintenance Lead is appointed by the JSR's current Spec Lead to promote and oversee this work. A Spec Lead can assume that role or pass it on to another participant, typically someone who has been intimately involved in the specification process as an Expert Group member.
 |
|
| David Nuescheler |
|
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 its second version, JSR 283. When JSR 170 was released, David simply stayed on as its Maintenance Lead. He says,
"It was a natural transition at the tail end of JSR 170. Since we did not know exactly how much change we were going to make in JSR 170 before we would release its second version, as the Spec Lead of both JSR 170 and JSR 283, I seemed like the most convenient candidate."
David recommends that maintenance considerations be factored into the specification process early on. For example, if the Maintenance Lead will not be the same person as the Spec Lead, it can be helpful for the Expert Group to understand this ahead of time. Involving the Maintenance Lead in the specification process can help establish the community's trust and expectations. A Maintenance Lead who has served continuously through the process and participated in early discussions and decisions will have a robust historical background from which to respond to the community's pleas for this or that addition or change. A person who already knows they will eventually become the Maintenance Lead can prepare proactively to meet that challenge.
 |
|
| Antti Rantalahti |
|
Antti Rantalahti is a research manager at Nokia Research Center. As Nokia's technical lead of JSR 135, Mobile Media API, and then the Star Spec Lead, he was involved with the JSR from the beginning. "It was quite natural for me to take over since most of issues in the maintenance phase are technical." Antti finds that those who are highly involved in the specification effort are well prepared with the necessary experience, skills, and knowledge to get through the maintenance phase.
 |
|
| Mike Milikich |
|
Because the maintenance phase of a JSR never ends, Maintenance Leads can be appointed years after a JSR has gone final. Mike Milikich is the Java ME Technology development manager for Motorola Mobile Devices. As the Star Spec Lead of JSR 271, Mobile Information Device Profile 3, and co-Spec Lead of JSR 307, Network Mobility and Mobile Data API, Mike has a history of assuming the role of Maintenance Lead after the original Spec Leads-who-became-Maintenance Leads moved on to other tasks within the JCP program. He notes that this kind of movement is "quite common in JCP related activity." In this way, Mike became the Maintenance Lead for JSR 82, Java APIs for Bluetooth, and as soon as JSR 271, MIDP3, was filed, he also became Maintenance Lead for JSR 37, MIDP1, and JSR 118, MIDP2.
 |
|
| Danny Coward |
|
Danny Coward often finds himself in a similar situation. He is the Java Standard Edition (Java SE) platform lead at Sun Microsystems. Within the JCP program, he is a Star Spec Lead for numerous JSRs, such as his latest, JSR 308, Annotations on Java Types. Although he has never done a Maintenance Release, he is the Maintenance Lead for dozens of JSRs. He says, "I am automatically the Maintenance Lead on a number of JSRs because people quit or moved on or I put my hand up at the wrong time. But often, as in my case, there isn't much to do except monitor the feedback aliases and stay tuned for any problems, should they occur, until there are enough important ones to do a Maintenance Release of the spec."
Even if there is no Maintenance Release planned for a JSR, a Maintenance Lead has several things to do. The Maintenance Lead gathers, collates, and maintains a list of proposed changes, based on the incoming flurry of notes from the community. He or she plans out whatever corrective action would be appropriate, consulting with "whoever is still around in the Expert Group and/or people who are implementing the specification," says Danny.
If there are any substantive corrections in the spec, then the RI and TCK are also likely to need updated. Sometimes the input specifically refers to a problem with the RI or TCK. Antti Rantalahti recommends having a positive attitude about such feedback. He says, "It'sgood to keep in mind that implementation-specific questions probably mean someone is actually working with an implementation and a product.B Try to be responsive and as helpful as possible.."
This might sound easy, but David Nuescheler says that, for him, being responsive when he has already gone ahead to the next thing is one of the most challenging aspects of the maintenance phase. In his Maintenance Lead role, he has to focus on the needs of the community currently implementing the released JSR. At the same time, in his Spec Lead role, his focus is on developing the follow-on major revision.
 |
|
| Harold Ogle |
|
Harold Ogle, a program manager for the JCP Program Management Office (PMO), explains the maintenance process in a brief audio podcast. He says that when a Maintenance Lead thinks the list of proposed changes is "ready for public consumption," it's time to send it to the PMO, along with the relevant JSR number, an email address for collecting review comments, and the desired length of review, which can be 30, 45, 60, or 90 days long. Optionally, an updated version of the final spec, illustrating the list of proposed changes, can also be posted during review, as long as an evaluation license is provided for the draft spec.
The list of proposed changes is added to the change log on the jcp.org JSR page, in the "Proposed Changes" section, and the review is announced to the community. During review, a Maintenance Lead is welcome to add, remove, or update changes in the change log. However, in the last week of the review, the change log is typically frozen. Harold explains that if a Maintenance Lead feels it is advantageous to make changes during that last week, the review simply extends to the next increment of an additional 15-30 days. The review cycle cannot last longer than 90 days, so changes that would add too many days would be postponed until a second review cycle. The change log can be updated at other times without necessarily triggering a review.
Changes are automatically approved at the end of the review cycle unless the Executive Committee (EC) holds an item exception ballot to specifically exclude any of the proposed changes from approval. Harold says, "You cannot alter approved changes, except by going through another maintenance review."
At some point after the review has ended, a Maintenance Lead may choose to submit an updated final release, called a Maintenance Release (MR). Knowing when -- and even whether -- to make an official Maintenance Release is one of the toughest calls for the Maintenance Lead. There are good reasons both to publish and to wait, while some Spec Leads like David Nuescheler prefer to work on both the MR and new JSR simultaneously. A decision often depends on how the Maintenance Lead weighs the relative cost in terms of market demands, preparation, and content.
In Antti's experience, when companies start implementing the Application Programming Interface (API), they offer plenty of feedback on issues they see, quickly piling up sufficient material for the MR. However, Antti hesitates to move too quickly to address this pressure from the market because he believes it may be healthier in the long run to wait a while. He says, "It would be good to live for some time with the 1.0 version just to keep things stable long enough to allow the first wave of implementations to be released. After that you can be relatively confident that you know the majority of the issues that should be fixed."
A Maintenance Lead will also consider the amount of time and effort needed to prepare an MR versus a JSR. A new JSR takes at least a year to accomplish, partly because the process is highly structured and the involvement of an Expert Group is required. In contrast, the MR is "great for its light and relatively fast process" and its narrower scope of content, says Antti.
For Mike, the primary differentiator in choosing whether to create an MR or a new version of a JSR is the scope of the changes and additions to be made. He recommends that Maintenance Leads carefully define the scope and then resist the urge to fix things that are not within that scope. His rule is that "if the changes are in the scope of clarifications, a Maintenance Release is probably fine. But once the scope extends to new APIs, new functionality, or new packages, it's time to file a new JSR and convene an Expert Group."
Mike found that community input increased quite a bit once people became aware that a Maintenance Release was being prepared. He says, "Often, the idea of modifying the spec triggers a lot of requests for 'just one more thing' to be fixed. The problem is that API changes generally need to be avoided. It's very easy to make what seems like an independent or innocuous change that in reality may have far-reaching or conflicting effects on other parts of the spec."
Although there is no official definition of what content the MR should include, Antti notes, "The mind-set we have is that the MR fixes things and maybe introduces some critical new features but should remain binary-compatible with the original spec. A new JSR is the tool to bring major updates and new ideas via the new Expert Group."
The EC does not get too involved in maintenance activities until the end of the maintenance review. However, Mike takes a proactive approach to informing people about the change log. He advises Maintenance Leads to "circulate your ideas and the proposed change log for the Maintenance Release as early as possible to implementers, developers, and consumers of the spec. Listen to the feedback and concerns that you receive. Strive to make the contents of the Maintenance Release a surprise to no one."
Before a maintenance draft is released, and towards the end of the review period, the EC can review the items in the change log. During the last week of the review, any EC member may call for a ballot, called the item exception vote, to decide whether indeed to fix each item or to defer some of them to a future version of the spec.
Danny represents Sun on the EC. He says, "If you've done your homework with the Expert Group and with the people implementing your specification, it's unlikely the EC will object. That is, unless you propose major changes rather than just fixing small issues."
If the EC votes to defer a given item, it cannot be incorporated into the MR. "The only way for such a change to find its way into the spec is to go through a whole new JSR for that specification," says Harold.
Like many processes, maintenance goes on forever. As a result, there is no obvious end to a Maintenance Lead's role unless another person takes it over.
Antti points out that a question or TCK challenge can come in any day, even years after the last release of the specification. Moreover, the TCK may have an especially long life. Although the spec can't be touched outside the JCP process, the TCK can always be improved. Antti believes that over time it is important that in those areas where the spec is open for interpretation, the current Maintenance Lead should try to be consistent in addressing them. He says, "Implementing the TCK in one way or another helps to force the interpretation through."
The Maintenance Lead position isn't particularly demanding, but it does require a willingness to pay attention and persevere over what might be a very long haul.
Back to part 5...
|
|
