Java Community Process: Adopt-a-JSR

Java gehört Oracle, aber nutzen tun es viele. Eine tragende Säule der Verbreitung ist die gemeinschaftliche Standardisierung der Sprache und ihrer Funktionen durch den Java Community Prozess (JCP). Über den JCP wird viel geredet und die jüngeren Bemühungen, ihn transparenter und offener zu machen, zeigen deutlich, dass Oracle sehr daran gelegen ist, die Weiterentwicklung des gesamten Ökosystems in enger Zusammenarbeit mit den eigentlichen Nutzern und Lizenznehmern durchzuführen. Dennoch schwächelt die direkte Beteiligung der Java-Gemeinschaft an konkreten Java Specification Requests (JSRs).

Ein Grund mag die Angst vor dem Formalismus des JCP sein: Aus einer formlosen Registrierung auf der Webseite wird nämlich erst nach der Unterzeichnung des sogenannten Java Specification Participation Agreement (JSPA) eine tatsächliche Mitgliedschaft im JCP. Dieses Dokument ist einerseits rechtlich bindend, andererseits aber auch in schwer zu übersetzendem Englisch geschrieben. Viele Einzelpersonen scheuen sich daher zu unterschreiben. Darüber hinaus ist der Unterschied zwischen einfacher Registrierung auf der jcp.org-Webseite und tatsächlicher formal sowie rechtlich bindender Mitgliedschaft nicht allen bekannt.

Neben solchen Hürden gibt es noch die natürlichen Grenzen des Systems: In den Experten-Gruppen (EG) der einzelnen JSRs ist meist nur eine überschaubare Anzahl von Teilnehmern. Zwar verfügen mittlerweile fast alle JSRs über öffentliche Mailingslisten und haben einen users@xxx-spec.java.net-Alias, auf dem auch außerhalb der EGs diskutiert werden kann. Dennoch konnte diese Möglichkeit zur Teilnahme bisher nicht sonderlich viel mehr Außenstehende motivieren, zu den einzelnen JSRs beizutragen.

Das Programm "Adopt-a-JSR"

Um die rechtlichen und formalen Hürden kurzfristig auszuhebeln und die Mitarbeit mehr zu einem Gemeinschaftsereignis werden zu lassen, hat die London Java Community (LJC) Ende November letzten Jahres ein einzigartiges Vorhaben mit dem Namen "Adopt-a-JSR" gestartet. Dahinter verbirgt sich die Idee, die in der Java Community vertretenen Java User Groups (JUGs) direkter in die (Weiter-) Entwicklung von Java-Spezifikationen einzubinden - ohne die Formalismen des JCP und mit einem deutlich stärkeren Gemeinschaftsgefühl. JUGs unterscheiden sich extrem in Größe, Organisation und Rechtsform und reichen vom eher formlosen Zusammenschluss weniger Gleichgesinnter ohne Rechtsform bis hin zur als Verein eingetragenen, landesweiten Dachorganisation, die als gemeinschaftliche Stimme für mehrere JUGs fungiert. Gemeinsam ist ihnen, dass mehr oder minder regelmäßige Treffen zu bestimmten Technik-Themen aus dem großen Java Universum durchgeführt werden. Das "Adopt-a-JSR"-Projekt versucht mit einem losen Rahmen den verschiedenen Eigenarten gerecht zu werden.

Im Rahmen der einzelnen JUGs sollen sich nach der Idee des Programms Interessierte in beliebiger Form zusammenfinden und sich für einen gewünschten JSRs einsetzen. Die lokalen Arbeitsgruppen agieren selbständig und können auf die Erfahrungen und bereitgestellten Hilfsmittel des globalen "Adopt-a-JSR"-Programms zurückgreifen. Dabei versteht sich das globale Programm mit der offizielle Webseite auf Java.net als zentrale Anlaufstelle, die primär den Zweck hat, die vielen einzelnen Aktivitäten zu dokumentieren. Die LJC führt als konkretes Beispiel die eigenen Aktivitäten zum JSR-310 (New Date and Time API) an.

Die Zukunft von Java gestalten

Dank der "Adopt-a-JSR"-Initiative soll es viel mehr Einzelpersonen möglich sein, an der Weiterentwicklung einzelner Spezifikationen und der großen Plattformen (SE/EE) mitzuwirken. Vordringlichste Motivation für die lokalen Adoptions-Projekte könnte allerdings die Bewältigung der Sprachbarriere sein: Die Spezifikationen im JCP werden auf Englisch gemacht und auch ihre Weiterentwicklung sowie die Diskussion ist hier sprachlich stark fokussiert. Das kann sich wesentlich von der Arbeitsweise der JUG-Projekte unterscheiden. So ist einer der Vorteile, dass in der lokalen "Adopt-a-JSR"-Arbeitsgruppe Deutsch gesprochen werden kann und nur die zentrale Bereitstellung der Rückmeldungen an den Spezifikations-Lead des adoptierten JSRs in Englisch erfolgen muss.

Abseits der Sprache entwickelt sich auch der JCP weiter. Im Unterschied zu den frühen Jahren des JCP, in denen "Experten im Elfenbeinturm" die Spezifikationen bearbeiteten, ist ein möglichst frühes Berücksichtigen der Rückmeldungen aus der Nutzergemeinde heutzutage überlebenswichtig geworden. Niemand entwickelt mehr mit nutzerunfreundlichen APIs oder akzeptiert Produktivitätseinbußen, wenn es bessere Alternativen am Markt gibt. Das gilt vielfach nicht für den professionellen Einsatz. Die starke Verbreitung der Sprache und der darauf aufbauenden Plattformen ist grade im Enterprise-Segment ein Faktor, um den einzelne Entwickler nicht herumkommen. Hier ist der Weg für Alternativen daher meist versperrt. Getreu dem Motto: "Love it, change it or leave it" entscheiden sich die Teilnehmer am "Adopt- a-JSR"-Programm daher für die aktive aber formlose Mitarbeit an der Zukunft von Java.

Organisation des JUG-eigenen "Adopt-a-JSR"-Vorhabens

Es gibt keine Vorschriften für die konkrete Ausbildung des eigenen Adoptions-Vorhabens. Ein paar Vorschläge kommen allerdings vom globalen "Adopt-a-JSR"-Programm. Sie sind vergleichsweise einfach gehalten und schlagen beispielsweise einen virtuellen Diskussionsraum mit nahezu beliebiger Ausprägung (beispielsweise Mailinglisten, Foren, Skype) sowie eine gemeinsame Stelle zum Ablegen der Arbeitsergebnisse vor. Weitere organisatorische Maßnahmen sind nicht notwendig. Es muss lediglich vereinbart werden, auf welche Weise man sich mit dem Adoptivkind auseinandersetzt und wer die offizielle Kommunikation mit dem Spezifikations-Lead übernimmt. Empfohlen wird die Verwendung eines eigenen Java.net-Projektes, das sich auch direkt über die globale Adoptions-Matrix verlinken lässt. Konkret wird vermutlich jede interessierte JUG bereits geeignete Infrastruktur einsetzen, die genauso verwendet werden kann. Offizielle Empfehlung ist darüber hinaus die Dokumentation der internen Vereinbarungen in einem Wiki. Kurzum kann und soll hier jeder genau so viel oder so wenig machen, wie es in die bestehende Kultur der JUG passt. Wenn mehrere JUGs an einer Spezifikation mitarbeiten wollen ist wohl mehr Abstimmungsaufwand zu treiben.

Konkrete Aktivitäten

Die konkrete Mitarbeit kann sehr unterschiedlich ausfallen und ist von der Erfahrung und der zur Verfügung stehenden Zeit der Teilnehmer abhängig.

Den wichtigsten Punkt stellen die frühen Rückmeldungen dar. Welche der im Spezifikationsdokument formulierten oder in der API umgesetzten neuen oder geänderten Funktionen ist brauchbar? Welche Funktion geht an der Realität vorbei? Antworten zu diese oder ähnlichen Fragen können aus dem Aktivkreis eines adoptierten JSRs an die Expertengruppe oder den zuständigen Spezifikations-Lead gesendet werden. Auch ein umfangreicher Test der verfügbaren Referenzimplementierung und die Rückmeldung von Fehlern über den Bugtracker sind Beispiele für willkommene Hilfen in einzelnen JSRs.

Weiter weg von den konkreten Umsetzungen brauchen viele JSRs Unterstützung bei den alltäglichen Dingen. Das Moderieren von Mailinglisten oder die Pflege der zugehörigen Webseiten und Wikis sind Aufgaben, die von den Spezifikations-Leadern oder den EGs selten geleistet werden können. Darüber hinaus geht es nicht zuletzt um die notwendige Öffentlichkeitsarbeit. Neben dem Engagement in der eigenen JUG können gemeinsame Blogeinträge über die adoptierte Spezifikation oder die Verbreitung von relevantem Wissen über Social-Media-Kanäle Teil der Aktivitäten sein.

Näher am Sourcecode können Rückmeldungen über JavaDocs oder Beispielanwendungen sein. Aber auch Testfälle für das Technology Compatibility Kit (TCK), einer Referenz-Implementierung, sind bereits aus dem "Adopt-a-JSR"-Projekt für den JSR310 übernommen worden. Die Mitarbeit an der Referenz- Implementierung ist eine weitere mögliche Art der Beteiligung. Schlussendlich kann die offizielle Aufnahme in die Experten-Gruppe oder gar die Übernahme der Verantwortung als Spezifikations-Lead eine Option sein. Für beides sollten die Bewerber allerdings anerkannte Experten der jeweiligen Technik sein und entsprechend viel Zeit zur Verfügung haben.

Neben diesen, wohl bewusst allgemein gehaltenen, Vorschlägen ist seit ein paar Tagen auch eine konkrete Anforderungsliste für die Referenz-Implementierung von Java EE 7 und 15 darin enthaltene neue Spezifikationen verfügbar. Damit kann sich die größere Gemeinde der Java User Groups erstmalig auf direkten Wunsch der dort versammelten Spezifikations-Leads beteiligen.

Persönlicher Mehrwert

Neben der Tatsache, dass die lokale Java User Group ein großes Maß an Sichtbarkeit durch ihre Aktivitäten bekommt, hat die Teilnahme auch für den Einzelnen einen Mehrwert: Die durchaus herausfordernde Arbeit mit Spezifikationen ist für viele Arbeitgeber und Personalvermittler ein wichtiger Punkt. Wer sich hier erfolgreich bewegen kann, stellt nicht nur seine Technik-Kompetenz auf einem Gebiet unter Beweis, sondern zeigt auch den richtigen Einsatz von Soft-Skills. Für Nicht-Muttersprachler passiert all das zudem in einer anderen Sprache, manchmal sogar in einem weltumspannenden Team.

Wermutstropfen

Wenn sich eine JUG zur Adoption eines JSRs entscheidet, muss sie sich über eines im Klaren sein: Die formlose Teilnahme ist abhängig vom Wohlwollen des jeweiligen Spezifikations-Leads. Er und nur er hat das letzte Wort über die Berücksichtigung aller Rückmeldungen. Um die Chancen der Akzeptanz zu erhöhen, ist es wichtig, in engem Kontakt mit dem Spezifikations-Lead und der Expert Group zu stehen. Darüber hinaus müssen die gelieferten Rückmeldungen nicht nur technisch nachvollziehbar und verständlich, sondern auch sprachlich ausreichend korrekt sein.

Zudem hat der offizielle JCP-Status des jeweiligen JSRs Einfluss auf die etwaige Mitarbeit: Befindet er sich schon im sogenannten Public Draft ist eine Berücksichtigung der gemachten Vorschläge für das kommende Release nahezu unmöglich. Early Drafts bieten hier deutlich bessere Chancen, solange sich die Vorschläge im Rahmen des bereits umrissenen Funktionsumfangs der Spezifikation bewegen. Allen Vorschlägen gemein sollte sein, dass sie berücksichtigt werden. Wenn nicht im aktuellen, dann im nächsten Release. Ein Eintrag im Bugtracker der jeweiligen Spezifikation, für die ein Java.net-Account ausreichend ist, macht es den Spezifikations-Leads auch einfacher, die Menge im Überblick zu behalten. Damit jeder Bescheid weiß aus welchen Gründen die Einträge entstehen, raten die Initiatoren des "Adopt-a-JSR"-Programs dazu, dies in der jeweiligen Kommunikation deutlich zu kennzeichnen. Das bedeutet, dass Bugtracker-Einträge mit dem Tag "adoptajsr" versehen werden und in der Betreffzeile von E-Mails ebenfalls "Adopt-a-JSR" auftauchen sollte.

Deutsche JUGs bisher wenig vertreten

Auf der Adoptions-Matrix finden sich bisher nur die Namen von vergleichsweise großen, international bekannten JUGs. Deutsche sucht man bisher noch vergebens. Es besteht also Verbesserungspotential. In der Summe bleibt abzuwarten, wie die freiwilligen Helfer im Rahmen der einzelnen JSRs akzeptiert werden. Die Chancen für eine produktive Zusammenarbeit sind hoch und das Potenzial der Java-Anwender kann hier gut gezeigt werden. Ob die Selbstorganisation der vielen kleinen Initiativen mit zunehmenden Teilnehmerzahlen trägt und ob die Spezifikations-Leads tatsächlich in der Lage sind, umfassende und zahlreiche Rückmeldungen zu berücksichtigen, sind Fragen, die sich als Schwachpunkte der Initiative erweisen könnten. (jul)

Markus Eisele

ist Principal IT Architect bei der msg systems AG in München, Java EE 7 EG und JCP Member.

Links:

Review Copy vom JSPA (PDF)

Global "Adopt-a-JSR"-Program