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. |
|
JMX Spec Lead Éamonn (aymon) McManus is one of the
lucky ducks whose employer - Sun Microsystems - pays
him to spend a large portion of his working hours on
JCP program-related activities. Before joining Sun,
Éamonn worked for the Open Software Foundation (OSF),
where he began using Java technology in 1996 in some
cryptographic projects as well as in a number of
embedded software projects for Hewlett Packard
printers. Moving to Sun in 1999, he participated in
the development of what is now known as the Netra
High Availability Suite. A couple of years later he
became the architect for the Java Management Extensions
(JMX) team within the Java SE organization.
As JMX guru, Éamonn is closely involved with both
specification and conformance, ensuring that the
several implementations of the JMX spec are in fact
compatible with the specifications.
He's been busy with the following specifications:
JSR 3 Maintenance Lead of Java Management Extensions (JMX) Specification
JSR 160 Spec Lead of Java Management Extensions (JMX) Remote API 1.0
JSR 252 Spec Lead of JavaServer Faces 1.2
JSR 255 Spec Lead of Java Management Extensions (JMX) Specification, version 2.0
JSR 77 Observer of J2EE Management
JSR 224 Observer of Java API for XML-Based Web Services (JAX-WS) 2.0
JSR 244 Observer of Java Platform, Enterprise Edition 5 (Java EE 5)
JSR 166 Specification Observer, for personal interest, of Concurrency Utilities
JSR 175 Observer, for personal interest, of A Metadata Facility for the Java Programming Language
Éamonn, a veteran Spec Lead, has managed each of his Expert Groups
somewhat differently based on various factors, including lessons
learned, number of members, changes in available infrastructure, and
JCP program changes in the acceptable levels of transparency.
When JSR 160 was starting, ?amonn insisted on limiting
the number of people in the Expert Group because he
worried about the potential for an overwhelming number of conflicting
opinions. His concerns grew from experiences unrelated to JSR
development, "where we had the too-many-cooks phenomenon. In fact, that
was a bad time to limit the number of people in the Expert
Group to avoid there being too many conflicting opinions." What
?amonn discovered is that even in highly populated groups, the number who
are vocally active is considerably less than that. He say, "It
really doesn't matter so much that there are very many people, and if you turn
people away you may end up missing out on some very good people, as
happened with JSR160."
Possibly because the first Expert Group he led for JSR
160 included only 20 participants, ?amonn held conference calls
nearly every two weeks, particularly during the most active period of
discussion. Once most of the details had been decided, the conference call
schedule slowed to only address tricky issues or for when the email
discussion wasn't converging as quickly as was needed. With his more
recent JSRs that are still in progress, ?amonn hasn't felt the same
need for regular conference calls although he expects there to be
occasional phone conferences to discuss particular technical issues.
Currently, he finds the teleconferences most valuable for giving a new,
geographically distributed group of Experts the opportunity to
introduce themselves and say what they want to get out of a JSR, what
problems they want to see solved in the JSR, what their particular areas of
competence are, and so forth.
Experts generally live far apart, so ?amonn doesn't rely on face
to face meetings, although he did participate in one for
JSR 160 that included a teleconference option for those like himself who
couldn't attend in person. He recalls, "That was very productive although a
little bit of a handicap for those not physically present -- obviously
they don't have the same feedback, white-boarding and so on."
More typically, before the major JavaOne or Javapolis conferences, he polls each
Expert Group for who will be attending, then schedules an informal
gathering "to talk things over."
With the transition to JCP program version 2.6 came the requirement
for Expert Groups to operate in a more transparent fashion. This is
particularly important for the JMX JSRs, which enjoy a high level of
interest and visibility by virtue of being part of the Java platform
Standard Edition (SE) Development Kit (JDK). ?amonn says, "We have a
very large number of users in the sense that the Java platform has
more than a million developers. Even if only one in a thousand of those
developers is using JMX, that still gives us a thousand or more
developers who are using our stuff."
In an effort to operate transparently, ?amonn created an observer
alias for JSR 255, so that interested members could see how plans for
updating the JMX specifications were evolving. However, with the java.net
infrastructure in place, he began a JMX
blog and mostly let the observer alias lapse. "If I have something to
say to the observers, I might as well say it to the world at large by putting
it in my blog. I'm having some difficulty thinking of what sort of
things I'd want to say on the observer list that I wouldn't just put in
the blog." There is an observer list set up for JSR 262, but it's been a
nonstarter -- "I haven't used that at all," he says. The community does
not seem to miss the short-lived observer alias, and has tuned
into the blog with enthusiasm, offering considerable feedback in the form
of questions and suggested topics. The attention is "very rewarding," he says.
?amonn appreciates what the jcp.org has provided in terms of private
JSR pages. However, now that java.net allows him to communicate publicly
as well as privately, the Expert Group for JSR 262 is not updating the
jcp.org page beyond the usual boilerplate of basic information.
He says, "The java.net infrastructure is more powerful when it comes to
posting documents and so on. And there is an issue of access control.
If you want to allow someone to access stuff, we have to go through the
PMO to do that, whereas with java.net we can do it ourselves."
?amonn knows that the PMO is vital in other ways, and he says new
Spec Leads in particular "should be communicating quite closely with the
PMO well in advance of when things are actually ready. There is a
surprising number of details that need to be sorted out -- getting the stuff
onto the web, backed up, and details you might not think of. It's better
to tell the PMO about something that they may or may not need to do
anything with, than to not tell them and then discover at the last
minute that there's some action you haven't thought of." ?amonn keeps
in touch with the PMO via email, but he says, "I occasionally drop in
and say hello when I'm in Santa Clara or at JavaOne attending the
community event or walking the show floor."
?amonn doesn't always respond to the PMO as punctually as he'd like-
thank goodness for Liz and her reminders! - but a communication from
the Executive Committee (EC) would get his immediate attention as the
highest priority. He says, "If the EC expressed some concern, that
would basically be a show stopper. Just drop everything else and make sure
that whatever it is gets addressed. That's especially true for stuff
we're doing inside the JDK because there would be a risk otherwise of
delaying the release of Java SE -- that would be seriously embarrassing.
"It's also important to ?amonn to flag and reply fairly promptly to
messages from Experts raising issues. He says, "You really need to
keep the discussion going and not wait two weeks to reply. There's an
expectation that the Spec Lead is going to be the person who is
replying. I certainly wouldn't just not reply to a message, hoping
another person in the Expert Group will. I generally say something if
only, 'Oh yes, this is a valid issue. What do other people think of it?'"
Virtually every democratic leader would prefer to achieve consensus
on every issue on the table. But occasionally, when the opinions sharply
divide and stay divided over time, consensus simply isn't possible in
the short term, and efforts to achieve it waste time and energy. In
those cases, Éamonn has found that he must announce his intent to
side with the majority, "unless some killer argument in the other
direction comes up." This question of how to resolve differences arises when
the original JSR proposal is made. For recent JSRs, Éamonn considered
explicitly stating, "If consensus can't be reached, we will have a
majority vote." He's glad he never followed through because now he
believes "that would not be a good idea in fact. I think it's better
to discuss how to address these kinds of problems with the Expert Group
when the JSR starts." Éamonn notes that some general agreement is
usually achievable once issues are fully thrashed out.
Clearly, Éamonn prefers to involve the Expert Group in all major
decisions, but he has found that it often works best to propose a default
position and require people to take action if they want a different
outcome, rather than posing open-ended discussions where the silent
majority won't speak up. For instance, he might say,"I propose we
[fill in the blank: adjust the schedule this way, do a review on this date,
accept this nomination of a new expert]. Let me know if you have any
objection by a week from today." He finds that most people will agree
that the suggested method is as good a way as any to do it, or else
specific inputs will improve the original plan.
Éamonn has a BA and an MSc in computer science from Trinity College,
Dublin, Ireland, where he worked on a multi-processor operating system.
He sees the honor of being named a Star Spec Lead as"a good
acknowledgement that I'm doing something right."
Having English as his mother tongue, fluency in French, a smattering
of Spanish, and distant memories of the tricky Gaelic grammar, Éamonn
enjoys linguistics, comparing and contrasting the features of
language groups. He also finds pleasure in playing the piano, giving
classical concerts or playing rock, ragtime, or Brazilian music with
other ragtime musicians. In France, June 21 is a national music festival
day -- la Fête de la Musique. For half a day or so, employees typically
show off their musical talents. Éamonn is already thinking about what
he will play for his Sun colleagues next year. Stay tuned; the selection might
include extracts from Mussorgsky's Pictures at an Exhibition.
Go to the Star Spec Lead Program page for more information.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
|
 |
|
Éamonn McManus