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.

Éamonn McManus
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.
    Adjust for the Expert Group Size
    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."
    Cater to High Visibility JSRs with Transparency
    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 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 has provided in terms of private JSR pages. However, now that allows him to communicate publicly as well as privately, the Expert Group for JSR 262 is not updating the page beyond the usual boilerplate of basic information. He says, "The 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 we can do it ourselves."
    Aim for Punctual Communication
    ?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?'"
    Make Decisions with Group Input
    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.
    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .