Part V, Managing RI and TCK Development
If the process of managing a Java Specification Request (JSR) were a thriller movie, warning music would rise in volume whenever the TCK or RI parts of the project came into view. Creating the specification is no easy thing, but the prospect of managing the development of the Reference Implementation (RI) and Technology Compatibility Kit (TCK) can seem especially daunting to some Spec Leads. Although other standards bodies dont require both, the tremendous benefit of offering both to the wider developer community outweighs the inconvenience of creating them.
 |
|
| Linda De Michiel |
 |
These two essential parts of the final JSR are so challenging and complex that Star Spec Lead Linda DeMichiel of Sun Microsystems feels it is important to have an organization behind you to pull it off. Linda is chief architect for Enterprise JavaBeans (EJB) and Java Persistence at Sun Microsystems, and she has led JSR 19, EJB 2.0; JSR 153, EJB 2.1; and JSR 220, EJB 3.0.
Sometimes Spec Leads ask other organizations to handle the task for them. According to the Program Management Office (PMO), in 2005 Sun was creating more than 80 percent of the TCKs that come out of the community. Over the years, Sun has worked to lower that number by enabling engineers to develop their own TCKs. Sun provides tools, including a freely available test harness, to save development time.
No matter who undertakes these tasks, whether members of the Expert Group, the Spec Leads own supporting organization, or another experienced group, there are two keys for making sure the RI and TCK are accomplished well and in a timely manner. Those keys are early scheduling and proactive communication. Stephen Caruso is the senior software manager for Java EE Compatibility at Sun Microsystems. During the Spec Lead training session held at JavaOne 2007, Steve put forth the need for Spec Leads to establish a team for each of the JSR projects -- specification, TCK, and RI -- and to get these teams together early and get em talking.
Spec Leads have a lot of leeway when they are deciding when to start work on the TCK and RI. In the early years of the JCP Program, Spec Leads often waited until later in the process to start developing their TCK and RI, and some still follow that plan.
 |
|
| 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 JSR 283, Content Repository for Java Technology API Version 2.0. David recommends starting RI development reasonably early in the process, around the time of public review. He says, This allows the Expert Group to validate the specification in real life. However, he prefers to start the TCK assembly relatively late in the process since the TCK has quite a number of requirements when it comes to spec coverage.
 |
|
| Danny Coward |
|
Some Spec Leads realize it is not necessary to wait until the specification is close to its final form. Danny Coward is the chief architect of Client Software 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 is a strong believer in starting early on both RI and TCK. He thinks its best if work can start on both soon after the Early Access draft and before the public draft, that is, when there are major stakes in the ground with regards to the APIs. At this stage, he knows the spec will change, but he believes it is better to start early and make sure that what is being specified can be implemented, and is testable.
Danny suggests that Spec Leads try to keep both the RI and TCK up-to-date with current drafts of the specification. Keeping them hidden during the months of development can be counterproductive. He says, Make them as widely available during development as possible. You'll get better feedback and figure out problems early.
Who Creates It?
The Spec Lead is responsible for deciding who will create the RI and TCK. As an employee of Sun, Danny has always been able to form RI and TCK teams with the support of the organization. He has always found experience and motivation of the individuals on the teams to be a key factor in the quality of the RI and TCK.
Steve maintains that JSRs focus on three different audiences: developers, licensees/implementers, and TCK developers. He urges Spec Leads to select diverse teams that employ representatives from all three. Dont show favoritism -- everyone needs to talk or it will be an enormous headache, he says.
Occasionally, the RI is created by people who are not in the Expert Group. This can create what Danny calls an uncomfortable but healthy tension. The tension can arise from problems with communication. He says, Sometimes it can get difficult to know who is calling the shots, but usually that's where the roles of the RI team and the EG are not made clear from the outset.
TCKs are typically created by engineers who are not part of the Expert Group. Thus, the TCK developers become a good sanity check on the decisions of the Expert Group. In this case, Danny says the Spec Lead has the additional burden of ensuring the TCK team is kept informed on what's going on with the specification.
How Does It Get Done?
The TCK has several components, including a test suite, a test harness, and documentation. Danny outlines an ongoing four-step process for developing the TCK. The first step is to read the spec and enumerate a list of assertions, statements that are supposed to be true about any implementation of the spec. The second is to write tests that verify those assertions. The third involves running the tests against the RI and making sure all the tests pass. The final step is to provide feedback to the Spec Lead if there are ambiguities in the spec and to fix any bugs in the tests. This cycle is repeated again and again to make sure the tests stay current with the ever-changing spec. Danny tells Spec Leads to expect that anyone who wants to certify an implementation of the tests will ask for a copy, and they will run them against their own implementations.
David doesnt recommend having the TCK and RI developed in isolation from each other. In fact, he thinks it makes sense to have the RI developers write test cases for the TCK since they understand the specification thoroughly. He says open sourcing both the TCK and the RI in a liberal open source license would help enable such useful transparency.
Instead of working toward a goal of having a TCK declared done, Danny says people more commonly think in terms of coverage, that is, what proportion of the requirements in the specification are covered by a test case. Ideally you want 100% coverage, but the world is not perfect. You are only done with the tests really when it tests everything in the spec, and when the RI passes the tests, and when you've fixed any bugs or issues reported to you by vendors who are running the tests on their own products.
Before the RI can pass any tests, it undergoes its own iterative process, as Danny explains. While consulting frequently with the Spec Lead, the RI engineering team reads the spec and creates software that implements all the required pieces of the specification. The RI may contaations and implementations will be even more portable, true to the WORA goal of Write Once, Run Anywhere.
Back to part 4...
Go to part 6...
|
