About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
|
|
|
|
|
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. |
|
When it comes to Java technology, Jim Van Peursem does nothing by half measures. He is drawn to all
aspects of Java technology that relate to mobile and wireless communication. He's delved into Java
technology in practically every way imaginable -- as user, project lead, developer, vendor, and so
on. Even his email signature, jvp, looks like a Java technology acronym. He started working with
Java technology in the very early days, say 1995-ish, before it was even integrated with the
Netscape browser. He jumped into the JCP program the minute the doors opened and has been
involved ever since as a member, participant, Expert, Spec Lead, and Executive Committee member.
Jim found the Java technology world irresistible. He remembers, "I had just worked on
two PDA development projects, where I got a good understanding of some of the challenges
developers face, as well as some of the challenges that manufacturers face in terms of growing
a developer community while maintaining the flexibility needed in making different hardware
choices in different generations of devices. The virtual machine (VM) architecture of Java
technology was attractive in isolating hardware changes from developers."
At Motorola, Jim is a Fellow of Technical Staff, holding a PhD in Computer Engineering.
He lives in Chicago, Illinois, near company headquarters. Jim was part of the Motorola team
that worked with Sun labs on the Spotless VM that became the KVM. From within Motorola, Jim
has been responsible for many aspects of Java technology deployment, from an independent
Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP)
implementations, to handset development, to working with the industry in defining many related
standards.
After working as an expert with Mark Vandenbrink in the original MIDP Expert Group
(JSR 37), Jim became its Maintenance Lead;
see also "Wireless Expert Group Divides and Conquers".
Jim led the MIDP2 effort (JSR 118) and is now leading the MIDP3 Expert
Group (JSR 271).
Jim also served as an expert on Java
Micro Edition specifications related to CLDC
(30, 248), CDC (249),
PDAs (75), web services (172),
mobile media (135), security and trust services
(177), the wireless industry (185),
and others.
MIDP is an essential technology. Based on the number of units shipped that incorporate it, MIDP is
arguably the most successful computing platform in the world. In addition, MIDP contains a lot of functional areas
that span a broad range of required expertise. Jim says, "As you can imagine, the combination of these two
factors means that a lot of companies and people want to join the Expert Group to shape the solution, and companies want to have
several people with different expertise to participate in the different areas. Contrary to some JSRs, we prefer to
adopt a more inclusive model and enable broad representation. This leads to much larger Expert Group than is typical.
"
For example, 122 people participated in the MIDP2 Expert Group.
With such a diverse set of members from around the world representing different markets and different
regions, there is a large challenge both in terms of communication as well as in reaching consensus and maintaining the JSR
schedule. Jim explains, "The way we approach this is to create separate email lists for each major topic
within the MIDP scope, and allow the relevant Experts of each company to sign up on the list they want to
participate in." Most of the discussions are conducted via email, with Jim leading nearly all the
discussions in every email list. However, in a few areas such as User Interface and Security, strong
sub-leaders Mark Patel of Motorola and Roger Riggs of Sun naturally took over leading the discussions in
those areas and keeping the Experts on task. Teleconferences are rarely used, due to the wide range of time
zones represented. The Expert Group meets face to face every six to eight weeks.
One of the Spec Lead's most critical tasks is to stay in constant communication with the Expert Group
members, who should all feel they have an equal voice in the direction of the JSR solution. This is especially tough
with such a large Expert Group, where, for example, face to face meetings are handled in a unique way. "It's not
practical to have a productive working meeting with 100+ people in a room. So what we did was create two segments of
members of the Expert Group. Those who had a direct shaping influence in the market, versus those who didn't." For example, in MIDP2 the first category consisted of device manufacturers and network operators, while everyone
else was placed in the second category. For MIDP3, VM vendors were moved into the first category since the spec
touches on some issues that dramatically impact VM vendors.
For each face-to-face meeting, every company within the first category is allowed to send one
representative. A few extra seats are reserved for people in the second category to attend. People are selected
from the second category using a kind of round robin lottery system, giving everyone a chance to attend at least one
face-to-face meeting if they want to. What gives all Experts an equal voice, however, is that everyone has full access
to the email discussions.
Laying out a schedule and keeping to it can be a significant challenge. What has worked well for Jim
is to break down the work flow of the JSR into clearly recognizable milestones,
and then to set goals for those milestones. "It's also important to structure the milestones such that there
are natural forcing functions, so everyone has to come to agreement before things can move on. That helps limit
the amount of redeciding decisions that have already been made."
Jim has discovered that there are a lot of things the PMO can do to help make a smooth transition
between phases if the Spec Lead involves them early enough, so he makes it a priority to communicate with the PMO
well in advance of each milestone within the life cycle of a JSR. For example, the PMO has checklists for things
they need in order to enter or exit each stage. For those who have the checklist and work with the PMO, it's easy
to be prepared to meet the schedule. Jim describes a typical scenario in which people want to publish a public
review, or meet some other milestone, right before the JavaOne Conference. They are inwardly focused within the
Expert Group to get everything ready, and then they mail it to the PMO right before the JavaOne Conference.
If they haven't already communicated their intention to the PMO, they then discover that they also need to provide
the PMO with other things, such as the export control legal document related to security, that they hadn't considered.
Jim says, "I've found that the people in the PMO are happy to work with a Spec Lead in understanding
how to get ready for the next phase of the process." In general, he keeps the PMO and EC in the loop on the Expert
Group's progress, especially in the longer phases of the process, so that they know progress is still being made in a
timely fashion.
Jim co-authored Programming Wireless Devices With the Java Platform, 2003, and the
second edition of Programming Wireless Devices with the Java 2 Platform, Micro Edition, part of
The Java Series by Addison Wesley.
His favorite activity outside of work is simply spending time with his family. He also enjoys the
unusual hobby of racing railroad handcars.
Go to the Star
Spec Lead Program page for more information.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|
|
|