Find JSRs
Submit this Search

Ad Banner

Star Spec Lead Profiles

The Java Community Process (JCP) program applauds the community's Star Spec Leads. These leaders earned this honor through their efficient, prompt, and transparent communication with their Expert Group, the Program Management Office (PMO), and the Executive Committee (EC). They used community web pages, observer aliases, and other tools to communicate with their expert group, the JCP program community, and the public. They kept their Java Specification Requests (JSRs) on schedule by making sure their team stayed focused and felt appreciated. The JCP program congratulates and honors these Star Spec Leads.

Linda DeMichiel
Star Spec Lead Linda DeMichiel has had her fingers on the pulse of Java technology for almost as long as a pulse could be found. While working on object relational databases for the exploratory databases group at the IBM Almaden Research Center, she got involved with the emerging Java technology. Linda says it was "clearly a big improvement" over the C++ language she was using at the time.

In 1997, Linda was recruited into Sun Microsystems as the technical team lead of the group working on Java Blend, an object relational mapping tool for Java persistence. Two years later, having driven the project to its 1.0 release, she was chosen to guide the development of the second version of Enterprise JavaBeans through the JCP program. Linda submitted Enterprise JavaBeans 2.0 (EJB), which was approved as a JSR by the JCP EC.

Linda was thus involved in the JCP program from its very early days. She is now a senior architect in the Java Enterprise Edition (EE) group at Sun Microsystems and the chief architect for EJB and Java Persistence. Linda has been the Spec Lead for three EJB JSRs:

JSR 19 Enterprise JavaBeans 2.0
JSR 153 Enterprise JavaBeans 2.1
JSR 220 Enterprise JavaBeans 3.0

She also served as an Expert Group member on three other JSRs:
JSR 107 JCACHE - Java Temporary Caching API
JSR 207 Process Definition for Java
JSR 225 XQuery API for JavaTM (XQJ)

Gathering Experts from Downrev JSRs
Having an established history with a technology, as Linda has with EJB, and carrying it forward through several JSRs, holds definite benefits when it comes to Expert Group formation. Because they've observed or participated in the cycles of development, a number of candidates already know about the technology. In her case with forming the Expert Group for EJB 3.0, Linda says, "a number of the members from the previous Expert Group were well established as active contributors to the process, so I polled them to see if they were interested in continuing." Others weighed in as likely candidates when the JSR was posted.
Linda's task became one of filtering out rather than recruiting potential Experts. If they weren't already familiar to her, she checked their written applications, googled them to see what they had contributed to the community, and then conducted phone interviews with numerous qualified candidates. In those conversations, Linda explained her goals for the JSR, then asked what their technical background was, whether they had any suggestions for developing the JSR, and how they were willing to contribute to the effort.
The final selection of participants can be a balancing act. Linda says different people are willing to contribute in different capacities, "so you have to weigh the benefits of someone who might contribute only minimally with the unique skills they might bring to the group." She began EJB 3.0 with a group that had a good ratio of individuals to vendors, and various technologies were also represented. Later in the process six Experts from the JDO community were added to the EJB 3 EG as the work on the persistence technology expanded.
Linda's style of operating her group transparently helped the integration of the new EG members. Feedback aliases for gathering input from the Java community on all specification drafts have maintained open lines of communication and made the input available to all the Experts as well as to "lurker lists" of Observers in companies who have representatives on the JSR. In this way, everyone can stay abreast of any developments, issues, and concerns, says Linda.
Building on Ideas from Previous JSRs
Work on one JSR often generates the idea seeds for its successor. "There's always a point when you have to draw the line on new functionality coming into a JSR--even when there are ideas still in the pipeline--and get it out to the community. Then you look at it and wish you could have done x, y, and z, but those things become fodder for the next revision of the JSR," says Linda.
Before writing the JSR for EJB 3.0, however, Linda approached her quest for ideas in a different way. Linda participated in months of brainstorming sessions to determine how to improve ease of development for the Java EE 5.0 platform. At the same time, Linda conducted her own research into general criticisms of EJB 2.x, anti-patterns, and features developers had found too complex. "Until you can understand what needs to be fixed, it's hard to come up with a list of what your action items are," she says.
Linda also collected more information directly from audiences when she spoke at venues such as JavaPolis, JAX, TheServerSide Java Symposium, and the O'Reilly Conference on Java. She typically convenes an EJB Birds of a Feather (BOF) session at JavaOne primarily to take the pulse of the Java community and hear what features people would like to see in the technology.
Linda appreciates community feedback in all of its forms. After work on JSR 220 began in earnest, she posted an Early Draft Review (EDR) for JCP members and the Java community at large to examine. Linda was so impressed with the response that she released a second EDR and would have done a third EDR and even a second proposed final draft if there had been time. She says, "I've never been on a JSR that has gotten such tremendous feedback from the community, and we take that input quite seriously. I think the community is really excited both by EJB 3.0 and by Java Persistence."
The Technology Compatibility Kit (TCK) and Reference Implementation (RI) teams are also valuable sources of input. As those teams try to implement the specification or build test suites for it, they inevitably notice any mistakes, ambiguities, or gaps, which they relay to the Spec Lead for clarification. Although these kinds of questions come up late in the process, Linda regards them as essential to the process of refining a specification.
Coping with a Massive JSR
JSRs often turn out to be complex endeavors, but EJB 3.0 is unusually massive, including about 800 pages of spec, 500 of which were of necessity included from earlier releases in order to preserve backwards compatibility?a key aspect of the Java EE Platform. "I never dreamed we would be doing so much work on the EJB 3.0 JSR," says Linda. Clearly, the team approach is essential, and Linda keeps hers busy.
While the Spec Lead steers the Expert Group and has the responsibility for producing the specification documents and holding the final pen, Linda also allowed aspects of the work to be driven by Experts who had concrete ideas to propose. She says, "?Several experts were willing to step forward and assume responsibility for driving proposals in a particular area. We wouldn't have been able to accomplish so much if it hadn't been done that way."
Linda is not hesitant to invest quality time in building relationships with members of the group. With EJB 3.0 she spent a significant amount of time on the phone building up the team. "Concalls take a lot of the Spec Lead's time, but they help drive consensus in the group. Particularly with this JSR and especially early on, we were doing a lot of brainstorming and batting ideas around, and it was extremely helpful," she says. With such a massive JSR, any actual improvements in making discussions more productive reap big dividends in the ultimate efficiency of development.
Working with a Platform JSR
Leading a JSR that is part of a platform JSR such as Java EE 5.0 "poses additional challenges for the role of Spec Lead," Linda says, because it is essential that the platform technologies integrate well together. The ability to foresee the ramifications of a given feature on the future evolution of the technology becomes an important skill to exercise.
It's gratifying to know that the Java community is excited about EJB 3.0, but Linda says leading such a prominent JSR is a "real heavy responsibility because you know you're making decisions that are going to have a lot of impact."
Advice to Future Spec Leads
Linda notes that those who contemplate Spec Leadership of a major JSR are in for a lot of work to prepare for such a role. "A JSR is a big commitment," she says. For example, they would need in-depth experience not only with the technology, but also with gathering large-scale support, recruiting constructive, enthusiastic people, guiding a geographically dispersed, proactive team, and assessing honestly whether the technical decisions they are making are in the best interest of the community.
There's also the challenge of developing an RI and TCK, each of which is a time-consuming piece of work in its own right. "To produce those requires an organization behind you," Linda says. Or sometimes two organizations, in the case of a tight schedule or other constraints. For EJB 3.0, Sun Microsystems invited Oracle to join Sun in delivering the RI for the Java Persistence API.
Well-motivated JSRs based on existing technologies are more likely to be approved by the EC. When proposing a new JSR, Linda recommends putting forth a solid statement of its purpose and motivation along with a preliminary outline of what the tasks are and how they will be addressed. To gain more support, a potential Spec Lead can recruit supporters for the JSR. "With our platform JSRs, we poll members of the previous Expert Groups and ask if they would like to be listed as supporting the JSR," she says. Having supporters and a starting point lined up at the outset is an effective way to launch the work.
Looking Back
Linda has over fifteen years of experience with databases, distributed computing, and object-oriented systems. She worked with operating systems at XEROX. She worked on the Common Lisp Object System at Lucid, a startup company, while earning a Ph.D. in Computer Science from Stanford University. Later, during her more than eight years with the exploratory databases group at the IBM Almaden Research Center, Linda was highly involved in the object-relational extensions to DB2 and to SQL99. All these experiences have served her well in dealing with the technical challenges of EJB and Java Persistence and with the diversity of backgrounds among the members of her Expert Group.
Go to the Star Spec Lead Program page for more information.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .