The Java Community Process (http://jcp.org) defines the way Java standards are created. Through this process, members of the community are invited to work together in expert groups (EG) to create new Java specifications.
If you wanted to create a new specification, you would file a Java Specification Request (JSR) with the JCP Program Management Office (PMO). To date, there have been over 200 JSRs filed, and they're at various phases of development. Some have been finalized and are being deployed in products, while others are just getting started.
In this article, I describe my experiences at leading the expert group in a recent JSR - JSR-118: Mobile Information Device Profile 2.0. (To see a list of the JSRs and learn more about what their goals and statuses are, please visit http://jcp.org/jsr/all/index.en.jsp.)
As you would expect, the Mobile Information Device Profile (MIDP) 2.0 expert group created a new revision of the MIDP 1.0 (JSR-037) standard, which was finalized in September 2000 and is shipping in many devices around the world. Mark VandenBrink from Motorola was the specification lead for JSR-037, which means Motorola is the specification lead for the revised MIDP standards, including version 2.0. However, this time around, Motorola tapped me on the shoulder to lead, which turned out to be an interesting and challenging experience.
Creating the Expert Group
The expert group experience for JSR-118 was interesting both in terms of the technology we developed and the fact that it pushed the envelope of the JCP process. The JCP Executive Committee (EC) approved the JSR in April 2001 and the work began shortly thereafter. The first step is to form the expert group through a process called the Call for Experts (CAFE). During this phase, experts in the industry and members of the community are invited to join the expert group. For JSR-118, even this was a challenge. For a typical CAFE, the specification lead receives 15-25 applications to join the expert group, and accepts somewhere around 15-20. However, it was clear that MIDP was taking off in the marketplace and the number of individuals and companies involved was becoming significant.
For our CAFE, we received approximately 60 responses, so a choice had to be made whether to keep the group small and focused and include only a fraction of these applicants in the expert group, or to be inclusive and let everyone become involved. We ultimately decided upon the latter; the advantage of this choice is that it assisted the further adoption of MIDP in the marketplace by letting all interested parties have a voice in the direction it should go in. The risk, however, was the schedule. As you can imagine, getting 60 companies to reach a consensus on a decision is a lot more difficult and can take significantly longer than with 20 companies. We decided that the potential advantages outweighed the risks, and so jumped in with both feet. As a result, JSR-118 became the largest expert group attempted (and finished) in the Java Community Process, with approximately 60 companies and over 120 individuals participating from countries all around the world. This became a tremendous challenge in terms of communication (during the peak, I typically got 250+ e-mails per day), program management, diplomacy, reaching consensus, scheduling, etc.
With such a large expert group and the large number of people involved, some structure had to be provided to make the group manageable. The Java Community Process had defined the concepts of participants and reviewers so the specification lead could distinguish the levels of involvement of an individual or company. For JSR-118 the members of the expert group were each assigned one of these roles; however, in practice this distinction was rarely used. It was only utilized to decide participation in our face-to-face meetings.
Coordinating our face-to-face meetings was an interesting challenge. First, imagine the size of the meeting room (concert hall) we had to find to hold expert group meetings with over 100 people attending. Then imagine how unproductive such a meeting could be! To make the face-to-face meetings manageable, we limited attendance to approximately 30-35 (depending on how large the room was). Even at this size, it was a challenge finding rooms that could accommodate us in a productive round-table style (nonclassroom) setting. For each meeting, the participants were given the first chance at claiming a seat. After the participants responded, the reviewers were given a chance to claim the remaining seats. For each subsequent meeting, preference (after participants) was given to reviewers who had not previously participated in a face-to-face meeting. In this way, all reviewers were given a chance to attend at least one meeting.
The vast majority of our expert group communications took place via e-mail. To make this manageable, several topic-specific e-mail lists were set up. In the MIDP 2.0 JSR, several technical areas were listed for development; one list was created for each of the 13 topics being developed in the expert group. Then all members of the expert group were invited to subscribe to the lists they were interested in, and more than one person from each company could participate. In this way, the relevant experts on each topic from within each company could participate in each of the subareas. This was advantageous for three reasons:
1. It was easier to keep the discussion threads together so they could be followed more clearly.
2. Not all members had to deal with all the messages (they subscribed only to the areas they were interested in).
3. The experts from each company associated with each topic could participate, which made the discussions more efficient than if all communications had to be funneled through one representative per company.
Defining the Technology
Once the expert group was created, the development process began. As filed, the JSR described the scope for the expert group to be:
The JSR also listed the functional areas to investigate, including:
- Backward compatibility with MIDP 1.0
- Continued focus on small, high-volume wireless phones
- Maintain tight footprint objectives to limit growth in the core APIs
- Information learned from MIDP 1.0 deployments to fine-tune MIDP 1.0 APIs
- Focus on core functions needed by all devices and applications
- Focus on enabling m-commerce, service-based applications
Domain security model, including signing of applications and verification of certificates
HTTPS and secure networking
Network connectivity via sockets and datagrams
Formal inclusion of OTA Provisioning (i.e., Recommended Practice 1 for MIDP 1.0)
Push architecture - external events and messages routed to appropriate MIDlets
User interface - extensions to low-level LCDUI to allow greater game functionality and layout control for larger screen sizes
A small, efficient XML parser to enable platform-independent data exchange
Base sound API
Given broad goals and functional descriptions like these, the expert group's first step was to examine each area and agree on the requirements. Our first face-to-face meeting in June 2001 was therefore dedicated to refining the scope of the JSR and coming to an agreement on these requirements.
After we reached consensus, it gave us a basis for agreement upon which we could start the design of the APIs. A call for design proposals was issued, and several proposals from different companies and individuals were distributed and discussed via e-mail. In some areas, only one proposal was received, while in others there were competing proposals. The expert group members then focused on comparing the features and merits of each proposal. After the debates and discussions evolved for a while, it became clear that the competing proposals in some areas were starting to evolve independently, not driving toward a merger. Since ultimately it made sense to specify only one API for a given functionality, I set a deadline for choosing one basis proposal in each area. This basis would then be the API that the expert group would focus on improving to meet the requirements we defined in the first meeting. In some cases, this meant combining the best elements from multiple proposals, but in most areas one of the proposals was chosen over others.
Once the basis proposal was chosen for each area, the expert group collaborated on refining the designs. This was the part of the process where the most debate and disagreements occurred. Most of the arguments centered around the naturally recurring tension between new features and the added cost that came with the associated increase in implementation size. On the one hand, since the target devices for this technology are extremely resource limited, we had to keep a close eye on the implementation budgets. This meant that some members of the expert group were constantly trying to reduce the feature set to lower the cost of implementation. On the other hand, there was obvious value to adding more functionality, as it enabled a richer set of applications. This tension is what caused most of the interesting debates in the expert group.
One of the unfortunate victims of these debates was the XML functionality. As we were developing this portion of the specification, it became clear that the implementation size was a very large percentage of our overall budget. Even after we trimmed its functionality down as far as we could without significantly crippling the design, it was still too large. As a result, we decided that a new JSR (JSR-172) should be filed for developing an XML specification for the MIDP market. In this way, those devices that can afford the extra implementation budget can incorporate this functionality, while those very cost-sensitive devices can choose to leave it out. It also allows the new expert group to have more freedom in terms of implementation budgets and features. The disadvantage is that XML developers can't rely on parsers being available on every MIDP platform.
Opening the Specification for Review
Once we brought the specification to what we considered a relatively stable point, it was time to get a larger audience to review it. In the JCP, the first step in this process is the Community Review. This is where the specification is published to JCP members so they can send their comments and feedback to the expert group. This review lasted 30 days, and we received around a dozen comments, which helped us improve the specification. During this time, the expert group continued to debate the features and improve the specification as well. We created a new draft of the specification, incorporating improvements both from internal debates and from the Community Review feedback.
The next step for getting an even broader review was to submit the specification for Public Review. This is where the specification is published openly so that anyone with network access can download it and send in their comments and feedback. This review also lasted 30 days, during which time we received nearly 100 comments. Reviewing and responding to all these comments was a significant effort that I had not anticipated. However, many of the public review comments resulted in new features being added, changes in design, and even simple (and useful) editorial clean up. Even though this created a lot of work, this feedback was beneficial and I would encourage you to get involved in providing feedback when JSRs are in Public Review.
The expert group continued to review the specification and work on clarifications when areas were found to be vague in meaning. At the same time, the Reference Implementation (RI) and Technology Compatibility Kit (TCK) teams started working on their implementations. As a part of the JCP process, an expert group must complete the specification, as well as an RI and TCK. At the time of this writing, the Proposed Final Draft of the specification has been submitted, and the RI and TCK are nearing completion. With any luck, by the time you read this, the specification, RI, and TCK will all be complete and available for download and implementation in your products.
Participating in the JCP is a challenging and rewarding experience. I would recommend it for anyone interested in the technologies being specified. Even if you don't have the bandwidth to become directly involved, you should become involved in the Public Reviews. The comments you send in are taken seriously and can have a direct impact on the designs being specified. This is your opportunity to shape and influence the APIs that you may want to use in the future. Don't pass it up!
James E. Van Peursem is chief architect for the J2ME platform at Motorola. He has been actively involved in the application of Java technologies in mobile wireless devices for as long as Java has existed. His contributions to external forums include being the specification lead for JSR-118 (MIDP 2.0) and interpretation guru for JSR-037 (MIDP) as well as being involved in the development of the JavaPhone APIs and the MExE standard within ETSI/3GPP. Jim received his PhD in computer engineering from Iowa State University.