Das Java-Jahr 2012 aus der JAXenter-Perspektive

JAXenter-Jahresrückblick: Das war Java 2012 [Teil 2]

Hartmut Schlosser

Wir lassen das vergangene Jahr 2012 aus unserer JAXenter-Perspektive Revue passieren. Die monatliche Zusammenschau der Ereignisse und Technologie-Entwicklungen offenbart die brodelnde Aktivität der Java-Community im Jahr 2012.

Mai


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/77/Larry_Larr50ea9e1e92cfb.png?1357553182″ hspace=“10″ vspace=“5″ alt=““>

Beginnen wir mit dem Streit der beiden Larrys – Oracle CEO Larry Ellison (Bild links) versus Google CEO Larry Page (Bild rechts). Am 23. Mai entschied die Jury, dass Google keine Patentrechtsverletzungen in der Android-Plattform begangen hat. Damit war klar, dass der Schadensersatzforderung Oracles, die sich im Vorfeld in Milliardenhöhe belaufen hatte, nicht nachgekommen würde. Auch in der Copyrightfrage hatte Oracle letzlich das Nachsehen. Am Ende wurden aus einem Korpus von 12 Millionen Quellcodezeilen in Android lediglich 9 Zeilen beanstandet. Google wurde dafür mit 150.000 US-Dollar bestraft, die Prozesskosten in Höhe von 1,1 Millionen US-Dollar hatte indes Oracle zu tragen.

Der Fall Oracle versus Google zog breite Kreise und führte zur Grundsatzfrage, ob APIs generell dem Copyright unterworfen werden können. Richter William Alsup erwies sich hier als weitsichtig – lernte im Verlauf des Verfahrens sogar selbst Java – und verglich APIs mit Bibliotheken, in denen die einzelnen Packages für die Buchregale stehen und jede Methode ein Kapitel eines Buches darstellt. Die Java- und Android-Bibliotheken seien zwar gleich aufgebaut und lösten die gleichen Probleme, so Alsup. Allerdings stellten die Android-Bibliotheken eine vollkommen eigene Implementierung dar, wodurch ein Copyright hier nicht greifen könne.

Ihre Meinung zu der Frage war übrigens deutlich: 80% stimmten in unserem Quickvote mit Nein – APIs sollten nicht durch Copyright geschützt werden können. Auch der Europäische Gerichtshof sieht dies so. Sebastian Meyen kommentierte auf JAXenter: „Gut gesprochen, Richter!“

Wer glaubt, dass ein rechtlich sauberes Softwareprodukt zu 100% von dessen Urheber selbst geschrieben sei, unterliegt einem fatalen Irrtum und offenbart eine krasse Unkenntnis darüber, wie Softwareentwicklung – ja Innovation im Allgemeinen! – heute funktioniert. Wir müssen Software heute im Sinne von Bausteinen denken – der eine schreibt den Code, der nächste entwickelt ihn weiter und ein Dritter macht etwas völlig anderes daraus: So entstehen immer höhere Ebenen der Innovation. Diesen Prozess zu fördern ist der Segen der Open-Source-Lizenz, die aber offenbar mit einem völlig überkommenen Patentrecht in Konkurrenz steht. Der gestrige Richterspruch setzte daher ein wichtiges Zeichen.

Auf technologischer Seite trat im Mai erstmals das neue Framework Vert.x in Erscheinung. Es handelt sich dabei um ein von VMware gesponsortes Framework für die Programmierung asynchroner, skalierbarer und nebenläufiger Anwendungen, das von manchen als JVM-Alternative für Node.js gehandelt wird. Ein Framework mit Potenzial, meinten viele von Ihnen.

Zwei weitere Premieren gab es im Mai. Zum einen veröffentlichte Atlassian sein neues Git-Verwaltungssystem Stash, das auf Enterprise-Bedürfnisse zugeschnitten ist. Außerdem erschien OpenOffice 3.4 – erstmals als offizielles Projekt der Apache Software Foundation. Weitere spannende Releases waren JBoss Errai 2.0, Caciocavallo 1.1, Eclipse Gyrex 1.0, ActiveMQ 5.6.0 und Drools 5.4. Eine interessante Personalie: Java-Veteran Simon Phipps wurde Präsident der Open Source Initiative (OSI).

Der meistgelesene Artikel im Mai auf JAXenter war „Die 15 populärsten Mythen in der Software-Entwicklung„. Wir berichteten über eine Frage nach typischen Entwickler-Irrtümer auf Quora.com, die solche Blüten zum Vorschein brachte wie:

  • Die beste technische Lösung gewinnt.
  • Die besten Software-Entwickler sind diejenigen, die gut in Mathe sind.
  • Wer nicht gut mit anderen Menschen umgehen kann, sollte Software-Entwickler werden.
Juni


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/85/Mike_Milin50eaadef5db5b.jpg?1357557231″ hspace=“10″ vspace=“5″ alt=““>

Der Juni steht in der Java-Welt seit Jahren für einen Garant besonderer Art: Auch 2012 fuhr der Eclipse-Release-Train pünktlich Ende Juni ein, diesmal mit dem Titel „Juno“ versehen. Mit an Bord waren 72 Projekte, die ihre Releases auf die neue Version der Eclipse-Plattform abstimmten. Und diese neue Eclipse-Plattform war denn auch der eigentliche Star des Sammelreleases, wurde doch zum ersten Mal die 4.x-Entwicklungslinie zur Basis aller Projekte genommen.

Eclipse Juno basiert also auf der neuen Plattform Eclipse 4.2, die mit technologischen Altlasten der 3.x-Linie aufräumt. Über einen Modell-getriebenen Ansatz wird die individuelle Gestaltung von Eclipse flexibler (die traditionelle Struktur von Editoren und Views lässt sich komplett verändern und per CSS stylen). Ein auf Dependency Injection basierendes Programmiermodell vereinfacht zudem die Plug-in-Entwicklung.

Etwas Ernüchterung machte sich dann allerdings in den nachfolgenden Wochen breit, als einigen die schlechtere Performance von 4.2 gegenüber der 3.8-Version auffiel. Bekannt wurde auch, dass aufgrund von Ressourcenmangel im Plattform-Team nicht genügend Regressionstests und Codeabdeckungsanalysen durchgeführt werden konnten.

Mike Milinkovich (Bild), Exekutiv-Direktor der Eclipse Foundation, gestand hier gewisse Strukturprobleme ein, wies aber auch darauf hin, dass ein Umstieg auf eine neue Plattform nie ganz reibungslos verlaufen könne. Dankend nahm er jedenfalls die Hilfe Googles an, das der Eclipse Foundation Hardware-Testinfrastruktur zur Verfügung stellte. Und tatsächlich wurde der ein oder andere Performance-Flaschenhals in Eclipse 4.x im Zuge der 4.3-Entwicklungen bereits beseitigt.

Wie unser Quickvote zeigte, wollten im November 2012 noch 31% auf Eclipse 4.3 warten. 37% fanden: „In Eclipse 4.2 läuft zwar noch einiges nicht optimal, dennoch bin ich zufrieden mit der Umstellung auf eine innovativere Plattform“.

Highlights in Eclipse Juno waren u.a. die neuen Projekte Code Recommenders (intelligente Codevervollständigung), Virgo (ehemaliger SpringSource dm Server) und Koneki (IDE für die Sprache Lua, maßgeblich von der neuen Eclipse M2M Industry Working Group in die Wege geleitet). Zudem sollte man den OGSi-R5-Support in Equinox, den DSL-Debugger in Xtext, die Browser IDE Orion, den Eclipse-Team-Provider EGit und die Common Build Infrastructure auf Basis von Hudson und Maven Tycho erwähnen. (Tipp: Zur Einführung in Eclipse 4 haben die Kollegen von entwickler.press das Buch „Eclipse 4 – Rich Clients mit dem Eclipse 4.2 SDK“ von Marc Teufel und Jonas Helming ins Programm aufgenommen.)

Neben Eclipse gab es noch zwei weitere herausragende Neuversionen: Zum einen erschien die Version 2.0 der dynamischen Sprache Groovy, die nun auch statische Typen-Überprüfung und Kompilierung beherrscht. Wir sprachen mit Groovy-Mastermind Guillaume Laforge über das neue Release, der meinte: „Verstehen Sie mich nicht falsch, wir lieben Java und promoten Groovy gewöhnlich als „Javas Cousine“ oder „Javas beste Freundin.“

Bei einer halben Million Groovy-Usern ist es klar, dass die Sprache völlig unterschiedlich eingesetzt wird und nicht jeder dieselben Dinge braucht. [.] Deswegen lag in diesem Release unser Augenmerk auf Sicherheit, Performance und Modularität.

Zum anderen wurde nach vier Jahren Entwicklungszeit die erste Majorversion des Build-Werkzeugs Gradle freigegeben. Gradle-Chefentwickler Hans Dockter nannte uns als sein persönliches Highlight in Gradle 1.0 das Dependency Management und den neuen Cache:

Wir sind hier dabei, komplett neue Türen aufzustoßen, z. B. neben sinnvollen Default-Verhalten die volle programmatische Kontrolle über den Cache, das Verhalten bei Versionskonflikten und sogar über die Metadaten zur Dependency-Resolution. Das alles wird Schritt für Schritt über öffentliche APIs zugänglich gemacht. Ein sehr mächtiges Handwerkzeug für Plugin-Autoren und Enterprise Build Master.

Und wo wir gerade noch bei den Releases sind: Im Juni gab es auch Vaadin 6.8, die JBoss Enterprise Application Platform 6, Griffon 1.0 und das Tool Javeleon 2.0, mit dem sich Java-Klassen dynamisch nachladen lassen. Auf der Google I/O wurde Android 4.1 alias Jelly Bean vorgestellt.

JAXenter-Artikel des Monats wurde „Das Problem mit der Architekturqualität“ von Uwe Friedrichsen. Spannend zu lesen, wie man durch einseitige Prioritäten viel Geld verschenken kann: „Kosten stehen über Qualität, billig sticht gut. Aber ist die schnelle billige Lösung automatisch die beste Wahl?“

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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