Java – The Community of Whiny Bitches

Hartmut Schlosser

Offenheit und Transparenz, das sind Tugenden, die von vielen Vertretern der Java-Community gefordert werden, wenn es um den Umgang Oracles mit Java geht. Betrachtet man sich allerdings die jetzt schon gegebenen Partizipationsmöglichkeiten an Java, lässt sich feststellen, dass diese keineswegs so aktiv wahrgenommen werden, wie sie könnten. Hand aufs Herz: Wer hat schon einmal einen Bug in Java gemeldet, geschweige denn sich am Fixen des selbigen beteiligt? Wer arbeitet wirklich mit am OpenJDK? Wer hat sich die „Meet the Candidates“ Sessions zu den JCP-EC-Wahlen angeschaut und wer hat die unter dem Stichwort JCP.next entwickelten neuen JCP-Richtlinien durchgesehen?

Gemach, gemach! Sicherlich ist es immer so, dass bei einem noch so offenen Software-Projekt der Großteil der Nutzer sich passiv verhält und ein Führungsgremium aktiver Committer die Dinge vorantreibt. Doch was ist mit der Aussage, die Java-Community sei zwar schnell dabei, sich zu beklagen, reagiere aber weitaus träger, wenn es darum gehe, selbst Hand anzulegen? Was, wenn Ted Newards provokante Aussage zutrifft, die Sebastian Meyen auf seiner W-JAX-Eröffnungsrede nochmals zitierte: Die Klagen über Bugs in Java 7 könnten eine Lektion für Oracle darstellen, „that the community is basically made up of a bunch of whiny bitches who complain when a workaroundable bug shows up in their products.“

Machen wir einen kleinen Gedankensprung: In der Tat lässt sich feststellen, dass sich nach der Veröffentlichung von Java 7 die Meinungsäußerungen häufen, Oracle habe seine Sache eigentlich ganz gut gemacht – schließlich gebe es nach Jahren des Stillstands endlich wieder ein neues Java-Release. Auch der Roadmap für Java 8 wird Vertrauen geschenkt, JavaFX 2.0 weckt Hoffnungen, Java könnte endlich auch Client-seitig glänzen. Java EE geht konsequent den Cloud-Weg.

Und in Sachen Offenheit hat Oracle eine Reform des JCP in Planung, die gerade unter dem Codenamen JCP.next erste Früchte trägt. Für JCP-Wahlen werden „Meet the Candidates“ Sessions organisiert. JSR-Expertengruppen müssen alle Diskussionen in öffentlichen Mailing-Listen führen. Ein für jedermann zugängliches Issue-Tracking-System soll eingerichtet werden. Die Arbeitsdokumente sollen veröffentlicht werden. Technology Kompatibilitätskits (TCK) sollen keine Klauseln enthalten dürfen, die verbieten, dass gewisse Themen öffentlich diskutiert werden können. Auch die Zugangshürden zum JCP sollen gesenkt werden.

Kurz: Keine durch Rauchschwaden vernebelten Räume mehr soll es geben, wie es Patrick Curran in einem Blogeintrag ausdrückt.

Doch birgt diese neue, selbst unter Sun nie gekannte Offenheit auch Gefahren, meint Java.net-Blogger Kevin Farnham. Die Spec-Leader müssten sich der öffentlichen Kritik stellen und dadurch einen großen Druck aushalten. In einigen JSRs sei bereits zu beobachten, dass die durch die neue Transparenz hervorgerufene Flut von Kommentaren nicht mehr zu bewältigen sei, beispielsweise im Project Coin JSR von Joe Darcy. Und so wird die Frage aufgeworfen, ob wir nicht wieder in die Gefahr von JSRs laufen, die sich aufgrund zu vieler Meinungsverschiedenheiten verzetteln und schließlich an der Meinungsvielfalt scheitern?

Zugespitzt ausgedrückt bedeutet das für Java als ganzes: Was nützt uns die ganze schöne Meinungsfreiheit, wenn sie zu Verzögerungen und verwaschenen Architekturentscheidungen in Java 8 führen? Was nützt es Oracle, sich auf die Meinungen einzulassen, wenn genau feststeht, dass die Umsetzung ja doch wieder auf die eigene Kappe genommen werden muss?

Sollten wir uns für Java nicht lieber an ein System gewöhnen, in dem Oracle die wichtigen Entscheidungen über den Java Core weitgehend alleine trifft – und auch umsetzt? Oder bevorzugen wir die Alternative eines offenen Debattierclubs, in dem zwar Meinungsvielfalt herrscht, in dem zu viele Köche aber letztendlich den Brei verderben? Austoben kann sich das Java-Ökosystem gerne in den unzähligen Frameworks, Projekten, Libraries und höheren Abstraktionen. Der Java Core benötigt aber ein performantes, stromlinienförmig geeichtes Entwicklerkerteam, das die vorgegebenen Spezifikationen einfach umsetzt.

Eine solche Meinung könnte man vertreten. Aber wahrscheinlich träfe sie das Selbstwertgefühl einer sich stets ein wenig elitär fühlenden Java-Community doch zu sehr.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.