Devoxx 2011

Vom 14. Bis 18. November fand in Antwerpen zum 10. Mal die Devoxx statt. Die Devoxx ist eine Konferenz für Java-Entwickler und wird von der belgischen Java User Group organisiert. Die Konferenz wartet jedes Jahr mit hochkarätigen Rednern auf und bietet eine gute Möglichkeit, sich mit Gleichgesinnten auszutauschen und so mehr über aktuelle Trends und produktivitätsfördernde Tools zu erfahren. Für mich war der diesjährige Besuch gleichzeitig auch der Erste und ich wurde nicht enttäuscht.

Devoxx 2011

Insgesamt fanden sich im Metropolis Business Center in Antwerpen über den Zeitraum von fünf Tagen 3350 Entwickler aus über 40 Ländern ein. Die Konferenz verteilte sich über zwei Etagen: Während in der unteren Etage Partner-Firmen ihre Produkte interessierten Besuchern präsentierten, gewährte die obere Etage Zugang zu den einzelnen Vortragssälen. Diese Räumlichkeiten sind im Prinzip für die Dauer der Konferenz umfunktionierte Kinosäle des benachbarten Kinos und boten einen hervorragenden Komfort. Zu den Sitzgelegenheiten vor den Sälen gesellten sich des Weiteren Community Whiteboards, über die aktuelle Trends von den Besuchern erfragt wurden (bspw. die Frage nach der Programmiersprache, mit der man sich – neben Java – am liebsten beschäftigt). Alleine durch diese Community Whiteboards konnte man die derzeitige Stimmung bei den Konferenzbesuchern gut erfassen. Die durchweg gute Organisation der Konferenz machte in den Sälen nicht halt: In jedem Saal zeigte die Leinwand eine Vorschau auf die nächsten Vorträge und zudem eine Twitter Wall, die mit #devoxx markierte Tweeds aggregierte. Eine gute Möglichkeit, um Feedback zu einzelnen Vorträgen zu erhaschen (die man womöglich selbst nicht besuchen konnte), aber auch um vortragsspezifisch weitere Ideen auszutauschen.

Die Vorträge selbst lassen sich thematisch verschiedenen Bereichen zuordnen. Entsprechend meiner persönlichen Interessen habe ich mir überwiegend Vorträge zu den Themen Java SE/EE, New Languages on the JVM und Architecture angesehen. Ich möchte in diesem Beitrag auf einige ausgewählte Vorträge näher eingehen und mit einem kurzen, allgemeinen Fazit zur Konferenz schließen.

Cracking Clojure / Stream Execution with Clojure and Fork/Join (Alex Miller)

Aufgrund meiner Affinität für neue Programmiersprachen und der Tatsache, dass ich mich bereits das ein oder andere Mal mit Clojure auseinandergesetzt habe, besuchte ich mit hohen Erwartungen den ersten Clojure-Vortrag “Cracking Clojure” von Alex Miller.

Der Vortrag richtete sich leider an Einsteiger in diese Sprache und ging dementsprechend nicht sonderlich in die Tiefe. Um dies zu bestätigen, hat Alex Miller anfangs dem Publikum die Frage gestellt, wie viele Leute im Raum bereits Clojure kennengelernt und eingesetzt haben. Von den geschätzten 250 Personen, die diesen Vortrag besuchten, meldeten sich vielleicht zehn Personen.

Rückschlüsse auf die Popularität von Clojure sind aber dennoch gewagt. Scala scheint beispielsweise bei den Konferenzbesuchern deutlich besser anzukommen, was die Umfrage auf einer der Community Whiteboards bestätigt hat, aber durchaus positiv für Clojure ist, dass dennoch einige der Besucher Interesse an der Sprache zeigten.

Viele Entwickler fragen sich, in welchen Szenarien sie Clojure aktiv einsetzen können. In seinem zweiten Vortrag “Stream Execution with Clojure and Fork/Join” zeigte Alex Miller einen Anwendungsfall aus seiner beruflichen Praxis auf. Der Vortrag an sich berührte Clojure eher oberflächlich und ging im Wesentlichen auf die Beschreibung dessen ein, was Alex Miller zu realisieren versuchte und wie er es letzten Endes auf hoher Abstraktionsebene abgebildet hat. Die Essenz dieses Vortrags ist, dass sich Clojure für die Stream-orientierte Verarbeitung von Daten durchaus eignet und die sprachlichen Mittel mitbringt, um einzelne Aufgaben in einem solchen System präzise und einfach in Form einer internen DSL zu beschreiben. Auch wenn der konkrete Anwendungsfall speziell sein mag, so zeigt er gut auf, dass sich Clojure in der Tat für die Umsetzung von Anforderungen aus realen Projektsituationen eignet.

Java: The Good, the Bad, and the Ugly Parts (Joshua Bloch)

Nachdem der Vortrag “Cracking Clojure” nicht sonderlich viel Neues für mich bot, habe ich mich kurzerhand entschieden, den Saal zu verlassen und noch einen Platz im parallel laufenden Vortrag “Java: The Good, the Bad, and the Ugly Parts” von Joshua Bloch zu ergattern. Leider war dies ein nahezu hoffnungsloses Unterfangen. Joshua Bloch ist ein sehr beliebter Redner und genießt ein hohes Ansehen innerhalb der Java-Community. Dementsprechend überfüllt war der Saal. Mir blieb also nichts anderes übrig, als einen Stehplatz in Kauf zu nehmen.

Der Vortrag gliederte sich in zwei Abschnitte. Im ersten Abschnitt reflektierte Joshua Bloch über die Design-Entscheidungen, die unmittelbar in die Entwicklung des JDK 1.02 (das ist schon 16 Jahre her!) eingeflossen sind. Insbesondere hob er einzelne Punkte hervor, in der Java für damalige Zeiten ungewohnte Wege ging, die sich aber im Nachhinein als vorteilhaft für die Sprache entpuppten. Ein kurzer Auszug:

  • Strikte Spezifikation von primitiven Datentypen (ein int umfasst immer 32 Bits)
  • Strikte Spezifikation der Auswertungsreihenfolge (immer von links nach rechts)
  • Syntax orientiert sich an C/C++: Zweifelsohne stammt der Großteil der Entwickler, die sich zu dieser Zeit für Java interessieren könnten aus der C/C++-Ecke. Dass sich der Syntax an C/C++ orientiert, förderte den Umstieg auf Java.
  • Keine Überladung von Operatoren: Operatoren haben in Java immer die gleiche Semantik.
  • Statisch-getypte Sprache: Ermöglicht eine schnellere Laufzeit-Umgebung und gute IDE-Unterstützung.
  • Objektorientierung: Objektorientierung war damals “cool” und wurde ähnlich wahrgenommen, wie heutzutage die funktionale Programmierung mit Scala oder Clojure.
  • Dynamisches Linken: Änderungen an einer Klasse erfordern das Rekompilieren der Klasse und ein neuer Build des JARs, in dem sich diese Klasse befindet. Ein kompletter Build der Applikation ist somit nicht mehr notwendig. Tatsächlich gibt es in Java aber die Möglichkeit, die Vorteile dynamischen Linkens auszuhebeln: Als final deklarierte Variablen und Konstanten werden inlined. Das bedeutet folglich, wenn man eine Konstante im Code modifiziert, dann müssen auch alle Klassen rekompiliert werden, die diese Konstante benutzen. Das verletzt das Prinzip der dynamischen Verlinkung und führt im schlimmsten Fall dazu, dass ein neuer Build der kompletten Applikation notwendig ist.
  • Concurrency-Support in Java und insbesondere auf JVM-Ebene (siehe hierzu auch die Aufsätze von Boehm (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf) und Buhr (http://plg.uwaterloo.ca/usystem/pub/uSystem/LibraryApproach.ps.gz))

Der zweite Abschnitt des Vortrags thematisierte das JDK 1.02 in kritischer Weise selbst. Joshua Bloch stellte Auszüge aus einzelnen Packages vor (tatsächlich umfasste das JDK 1.02 nur sieben Packages) und hob positive wie negative Aspekte hervor. Insgesamt ein sehr interessanter und unterhaltsamer Vortrag, auch wenn einige der Punkte, die Joshua Bloch präsentierte, dem routinierten Java-Entwickler bereits im Voraus bekannt gewesen sein dürften.

JDK 7, 8, and 9 (Mark Reinhold)

Die Devoxx bot mehrere Oracle-Vorträge an, die verschiedene Aspekte der aktuellen und kommenden Versionen des JDKs beleuchteten. Die Keynotes am ersten Konferenztag gaben bereits einen Vorgeschmack auf das, was später in einzelnen Sessions etwas ausführlicher thematisiert wurde.

Mark Reinhold, seines Zeichens Chief Architect bei Oracle, thematisierte in seinem Vortrag “JDK 7, 8, and 9″ insbesondere die neuen Sprachfeatures. Der Vortrag startete mit einem wirklich kurzen Überblick zu den Features, die das JDK 7 mit sich bringt. Ich empfand das als sehr positiv, da man an vielen Stellen bereits von den neuen Features gehört, gelesen oder sie selbst sogar schon eingesetzt hat. Aus diesem Grund möchte ich an dieser Stelle auch gar nicht näher auf das eingehen, was Mark Reinhold zum JDK 7 gesagt hat. Wer sich dennoch für eine kurze Vorstellung der Sprachfeatures des JDK 7 interessiert, der sei auf den Artikel meines Kollegen Martin Lehmann verwiesen (Link: http://www.accso.de/wp/2011/09/the-empire-strikes-back-oder-warum-wir-von-java-noch-einiges-erwarten-durfen).

Der thematische Schwerpunkt von Mark Reinholds Vortrag lag insbesondere auf dem JDK 8 mit einem kurzen Ausblick auf eine Feature-Liste, die als Ideensammlung für die Weiterentwicklung in Richtung JDK 9 dienen könnte. Ist das JDK 7 aufgrund seines Mangels an neuen, innovativen Features eher als evolutionäres Release einzustufen, so erwartet uns mit JDK 8 ein revolutionäres Release, das im Wesentlichen durch zwei Projekte getrieben wird: Project Lambda (JSR 335) und Project Jigsaw (JSR TBD). Neben diesen beiden Projekten gibt es ein paar weitere, kleinere Neuigkeiten. JSR 337 (http://www.jcp.org/en/jsr/detail?id=337) fasst den Umfang von JDK 8 zusammen:

Mark Reinholds erwähnte in seinem Vortrag zudem, dass Oracle eine Konvergenz der beiden JVMs JRockit und HotSpot anstrebt. Dies ist dem JSR 337 aktuell nicht zu entnehmen. Oracle wird sich, was die Release-Zyklen betrifft, wohl an einen 2-Jahres-Zyklus orientieren. Demzufolge ist das Release von JDK 8 für den Sommer 2013 angepeilt. Ich möchte im Folgenden kurz die wesentlichen Neuerungen beschreiben, die das JDK 8 durch Project Lambda und Project Jigsaw mit sich bringen wird und abschließend einen kurzen Ausblick auf die möglichen Features des JDK 9 geben.

Project Lambda

Project Lambda erweitert die Sprache um die Möglichkeit, Lambda Expressions (analog zu Closures) zu verwenden. Lambda Expressions sind den meisten von uns sicherlich nicht neu, nutzen wir sie doch schon ausgiebig in Sprachen wie C#, Groovy, Python, Scala und Clojure. Lambda Expressions in Java arbeiten in ähnlicher Weise wie ihre Pendants aus anderen Sprachen. Syntaktisch könnte das, nach Mark Reinholds Vortrag, folgendermaßen aussehen (Achtung, es besteht eine hohe Wahrscheinlichkeit, dass sich die Syntax bis zum endgültigen Release noch ändern wird!):

1: List students = ...;
2: students.parallel().
3:   .filter(s -> s.get)
4:   .map(s -> s.getGrade())
5:   .reduce(Math#max);

Dieses simple Beispiel zeigt bereits eindrucksvoll, wie mächtig die Anwendung von Lambda Expressions ist. Durch wenige Zeilen Code sind wir in der Lage, Collections zu filtern, zu transformieren und letzten Endes auf einen Wert gemäß einer weiteren Transformationsvorschrift zu reduzieren. Der Aufruf von parallel() initiiert hierbei die parallele Verarbeitung aller nachgeschalteten Filter- und Transformationsschritte. Möchte man eine derartige Funktionalität ohne Lambda Expressions ausdrücken, so ist deutlich mehr Code erforderlich. Lambda Expressions helfen dabei, boilerplate Code zu eliminieren und gleichzeitig die Intention des Entwicklers besser zu dokumentieren.

Die Einführung von Lambda Expressions ist eng gekoppelt mit sogenannten virtual extension methods. Eine virtual extension method stellt eine Default-Implementierung für Interface-Methoden bereit. Diese Default-Methode wird dann benutzt, wenn eine Klasse, die ein Interface implementiert, die Implementierung dieser Methode nicht bereitstellt.

Project Jigsaw

Project Jigsaw hat das Ziel, ein Modulsystem für Java zu realisieren. Daher zunächst die Antwort auf die Frage: Was ist ein Modulsystem und wie können wir davon profitieren?

Ein Modulsystem ermöglicht modulares Programmieren: Es erlaubt dem Entwickler Code in einzelne Module zu separieren, die wiederum Abhängigkeiten zu anderen Modulen bzw. bestimmten Versionen dieser Module besitzen können. Implementierungsdetails von Modulen können sich hinter Schnittstellen ändern, ohne dabei andere Module in Mitleidenschaft zu ziehen. Ebenso versteckt man durch Modularisierung eben diese Implementierungsdetails von anderen, externen Modulen. Die Versionierung von Modulen zeigt ihre Stärke dann, wenn es innerhalb eines Projekts notwendig ist, mehrere Versionen eines Moduls zu nutzen, um den Abhängigkeiten anderer Fremdmodule gerecht zu werden (transitive Abhängigkeiten).

Bezogen auf Java soll Project Jigsaw zum Einen dem Entwickler ein Werkzeug an die Hand geben, um Projekte entsprechend modularisieren zu können, ohne von den Schwächen des (noch) aktiv genutzten Classpath-Konstrukts abhängig zu sein (classpath/jar hell Problematik). Zum anderen soll das JDK selbst durch Project Jigsaw in einzelne Module unterteilt werden, die ganz nach dem Baukastenprinzip kombiniert werden können, um je nach Projektsituation ein JDK nach Maß zu erhalten. Das macht durchaus Sinn, denn das JDK ist in seiner jetzigen Form ein großes, monolithisches System. Ein JDK nach Maß würde die Komplexität nicht nur beherrschbarer machen, sondern auch für eine bessere Start-Up Performance und einen kleineren Memory Footprint sorgen. Mark Reinhold zufolge strebt Oracle damit auch eine Konvergenz bzgl. Java SE und Java ME an. Das JDK wird also in Zukunft für den Entwickler nur noch aus den Bibliotheken bestehen, die man tatsächlich für ein gegebenes Projekt benötigt.

Um dies umzusetzen, führt Project Jigsaw ein neues Sprachkonstrukt in die Programmiersprache ein: Das Modul. Die Definition eines Moduls erfolgt in Java Code und beschreibt im Wesentlichen die Bibliotheken, die es benötigt. Die Moduldefinition unterstützt zudem die bereits angesprochene Versionierung von Bibliotheken.

Die Einheit der Distribution von Java Code soll mit JDK 8 und Project Jigsaw nicht mehr das klassische JAR sein, sondern einem neuen Packaging-Format namens jmod folgen. Dieses Format soll nur zum Dateitransport genutzt werden, sprich, jmods müssen installiert werden, bevor man auf die Software zugreifen kann. Wer doch lieber JARs und dergleichen zur Verteilung nutzt, dem wird Project Jigsaw ebenfalls gerecht: Mit JDK 8 soll es möglich sein, ein Modul über verschiedene Packaging-Formate anzubieten, bspw. als JAR, als jmod oder gar als Debian- (deb) oder Red Hat-Package (rpm).

JDK 9

Im letzten Teil seines Vortrags lieferte Mark Reinholds einen kurzen Ausblick auf die möglichen Neuerungen, die uns mit JDK 9 erwarten. Die Fülle an Features ist ziemlich reichhaltig und hat derzeit eher den Anschein einer Ideensammlung. Es bleibt abzuwarten, ob Oracle in der Lage ist, alle angesprochenen Features tatsächlich in einem 2-Jahres-Fenster zu realisieren, so dass diese in das JDK 9 einfließen können. Jede weitere Erläuterung zu diesen Features wäre zum jetzigen Zeitpunkt rein spekulativer Natur, so dass ich die Liste der angeführten Features gekürzt und unkommentiert stehen lassen möchte:

  • Self-tuning JVM: Die JVM soll in der Lage sein, ihre Einstellungen auf Basis der Kapazitäten der Host-Maschine zu optimieren.
  • Improved JNI: JNI soll benutzbarer werden. Mark Reinholds sagte hierzu scherzhaft, dass das Design-Ziel bei der Entwicklung der ursprünglichen JNI-Bibliothek gewesen ist, die Benutzbarkeit so schwer zu gestalten, dass Entwickler davon absehen, JNI zu benutzen. Wer mit JNI bereits in Kontakt gekommen ist, der weiß, wovon Mark Reinholds spricht.
  • Unterstützung für extrem große Arrays und Collections (max. theoretische Anzahl von Elementen geht dabei in Richtung 2^63).
  • Reified Generics
  • Keine primitiven Typen mehr, um die Notwendigkeit von Autoboxing und -unboxing zu eliminieren
  • Tail Recursion und Continuations
  • Multi-Tenancy
  • uvm.

JRuby: Enhancing Java Developer’s Lives (Hirotsugu Asari)

Der Vortrag richtete sich an Einsteiger, die mit Ruby bzw. JRuby an sich noch nicht in Kontakt gekommen sind. So bot Hiro Asari zunächst einen kurzen Überblick über die Sprache selbst, indem er einige ihrer Konstrukte und Features vorstellte. JRuby ist eine dynamisch-typisierte Sprache, die auf der JVM läuft und so die Vorzüge dieser Laufzeitumgebung ausnutzt. Die Sprache bietet Einfachvererbung und folgt einem Methoden-orientierten Ansatz, sprich, der Konstruktor und auch das Pendant zum Java-Keyword new werden durch Methoden abgebildet. JRuby bringt einiges an syntaktischem Zucker mit: Bspw. ist @ ein Synonym für this und Standard-Getter und -Setter werden implizit durch die Definition von Klassenvariablen angelegt. Ähnlich wie in Scala oder Clojure muss man den Rückgabewert einer Funktion nicht explizit angeben. JRuby gibt implizit das Ergebnis der letztens Statement-Evaluation zurück, wenn der Rückgabewert einer Methode nicht explizit festgelegt ist. Die Sprache unterstützt ferner Operator Overloading und bietet Closures.

Nach dieser kurzen Einführung stellte Hiro Asari relativ ausführlich JRuby on Rails vor. Rails ist ein Web Application Framework, welches getreu dem Motto “Convention over Configuration” viele Annehmlichkeiten mit sich bringt. So bietet es Scaffolding durch Generatoren, die Controller, Stubs für Business-Klassen und die zugehörigen Testklassen liefern. Abseits dem Deployment von JRuby Code auf Rails kann man JRuby auch in bestehende Java Web Applikationen integrieren, beispielsweise durch schrittweises Ersetzen einzelner Controller. Der Rest des Vortrags thematisierte verschiedene Aspekte, die bei der Entwicklung mit JRuby relevant sind, zum Beispiel diverse Testing-Frameworks (RSpec, Cucumber, JTestr), Rake als Alternative zu ANT und Foreign Function Interface (FFI). Bei letzterem handelt es sich um eine einfache Möglichkeit, native Funktionen aus JRuby heraus aufzurufen. Hiro Asari zeigte anhand eines Vergleichs zwischen JNI und FFI, dass JNI doch sehr viel boilerplate Code benötigt, bis man zur gewünschten Lösung gelangt, während FFI einen minimalistischen Ansatz verfolgt und durch kurzen und gut verständlichen Code positiv auffällt. Nicht zuletzt zeigt diese Einfachheit auch, dass die Kritikpunkte an JNI, die Mark Reinholds in seinem Vortrag “Java 7, 8, and 9″ angesprochen hat, durchaus ihre Berechtigung haben.

NoSQL for Java Developers (Chris Richardson)

Chris Richardson gab in seinem Vortrag “NoSQL for Java Developers” Antworten auf die Frage, in welchen Szenarien der Einsatz einer NoSQL-Datenbank Sinn macht. NoSQL steht hierbei für “Not only SQL” und umfasst verschiedene Datenbankarten, die sich in Bezug auf ihre interne Speicherstruktur kategorisieren lassen.

Dazu zählen Key-Value-Datenbanken wie Redis, die Daten anhand von Key-Value-Paaren speichern. Redis als beispielhafter Vertreter dieser Kategorie überzeugt durch eine hohe Verarbeitungsgeschwindigkeit, was der Tatsache geschuldet ist, dass die Datenbank sämtliche Daten im Hauptspeicher der Host-Maschine hält. Redis bietet unter Performanz-Einbußen allerdings auch optional an, diese Daten zu persistieren. Ferner bietet Redis Transaktionen an und nutzt damit einhergehend optimistisches Locking, um den Durchsatz bei parallelen Zugriffen auf die Datenbank zu erhöhen. Redis bietet sich insbesondere als Ersatz für memcached an, um beispielsweise Session-Daten transient zu speichern.

Auf ähnlichem Niveau zeigte Chris Richardson an Vertretern von spaltenorientierten (Cassandra) und dokumentenorientierten Datenbanken (MongoDB) die Eigenschaften der jeweiligen NoSQL-Familie. Insbesondere MongoDB ist mir aufgefallen. MongoDB arbeitet ohne Datenbankschema und speichert Daten in Form von binären JSON-Dokumenten. Im Gegensatz zu relationalen Datenbanken ist dieser Ansatz schnell, denn ein solches binäres Dokument kann seriell von der Festplatte gelesen werden, während dies bei RDBMS unter Verwendung von Joins über mehreren Tabellen nicht der Fall ist. MongoDB unterstützt zwar Transaktionen, limitiert diese jedoch auf die Einheit eines JSON-Dokuments. Somit sind koordinierte Aktualisierungen über mehrere Datensätze mit MongoDB nicht möglich, was durchaus problematisch sein kann. Positiv hervorzuheben ist jedoch die reichhaltige Abfragesprache, die MongoDB zur Verfügung stellt sowie die Möglichkeit durch Replikation oder Sharding eine hoch-skalierbare Datenbankarchitektur zu etablieren.

Den tatsächlichen Wert dieses Vortrag sicherte aber der folgende Teil, in dem Chris Richardson anhand eines einfachen, aber dennoch praxisnahen Beispiels die angesprochenen NoSQL-Flavours praktisch vorstellte. Die Quintessenz des Vortrags ist im Prinzip, dass jedes NoSQL-Flavour für die Realisierung einer bestimmten Menge von Anwendungsfällen geeignet ist, bei denen relationale Datenbanksysteme Probleme zeigen. Aber kein NoSQL-Flavour löst alle Probleme von relationalen Datenbanksystemen. Kurzer Einschub: Dies führt uns auch ein Stück weit zum Begriff der Polyglot Persistence: Warum die Datenbankarchitektur nicht so auslegen, dass für bestimmte Anteile jeweils das dafür optimierte Datenbanksystem eingesetzt wird? Ich möchte an dieser Stelle auf einen Artikel von Martin Fowler verweisen, der den Begriff der Polyglot Persistence detaillierter umreißt (http://architects.dzone.com/articles/martin-fowler-polyglot).

Ein gewaltiger Nachteil ist sicherlich, dass NoSQL-Datenbanken aufgrund der limitierten Möglichkeiten zum Einsatz von Transaktionen und weniger starken Konsistenzbedingungen nicht konform zu den ACID-Eigenschaften arbeiten. Stellt man also irgendwann fest, dass man diese Eigenschaften zwingend benötigt, so erreicht man dies nur über umfangreiche Eingriffe in die Datenzugriffsschicht. Chris Richardson gab daher dem Publikum den folgenden, wohlgemeinten Rat mit auf den Weg:

“Do not commit to a NoSQL database until you have done a significant proof-of-concept.”

The Ceylon Programming Language (Emmanuel Bernard, Stephane Epardaud)

Neben Clojure, Scala, Groovy und dem in diesem Jahr veröffentlichten Kotlin gab es auch einen Vortrag zur Programmiersprache Ceylon. Glänzen die erstgenannten Sprachen bereits durch stabile Sprachversionen und den entsprechenden, wenn auch nicht immer zufriedenstellenden, Tool-Support, so gibt es diesbezüglich bei Ceylon noch so manche Lücke zu füllen. Für Ceylon gibt es aktuell noch kein Release. Interessierte können sich jedoch unter http://www.ceylon-lang.org detaillierte Informationen zu der Sprache selbst sowie den aktuellen Implementierungsstand über GIT holen.

Bleibt die Frage, warum man sich mit Ceylon näher beschäftigen sollte? Kurz vorweg: Der Vortrag hatte durchaus einige Schwächen, was allerdings auch am aktuellen Stand der Sprache selbst liegen könnte. So wurden dem Publikum nur anhand von sehr trivialen Beispielen einige der Sprachfeatures vorgestellt. Ceylon bleibt bewusst nahe an Java, versucht aber gleichzeitig, einige der Limitierungen von Java durch andere Lösungsansätze in den Griff zu bekommen. Dabei bedient sich Ceylon bewusst an Features aus anderen Sprachen. So bietet die Sprache u. a. Higher Order Functions, die man aus der funktionalen Programmierung her kennt oder aber auch ein im Vergleich zu Java mächtigeres Typsystem, dessen Basis durch sogenannte Principal Types (ML) gebildet werden.

Weitere Attribute, die den Charakter von Ceylon beschreiben, möchte ich im Folgenden kurz auflisten:

  • Syntaktisch nicht so überladen wie Java und damit deutlich lesbarer
  • Möglichkeit der deklarativen Repräsentation von hierarchischen Strukturen (bspw. XML, oder beim Erstellen von User Interfaces) direkt im Code
  • Keine primitiven Datentypen
  • Restriktive Art der Mehrfachvererbung über Mixins
  • Typsichere Behandlung von null
  • Typinferenz
  • Vereinfachte Generics mit reifizierten Typen
  • Kein Überladen von Operatoren, dafür aber Operator Polymorphismus
  • Support für typsichere Meta-Programmierung und Annotationen

Ceylon ist eine sehr junge Programmiersprache, die jedoch viele Dinge richtig zu machen scheint. Die Sprache scheint nicht aus reiner akademischer Neugierde heraus entstanden zu sein, sondern behält im Kern einen pragmatischen, leicht verständlichen Ansatz bei. Das klingt vielversprechend und ich werde definitiv den Entwicklungsstand von Ceylon weiterhin im Auge behalten. Nicht zuletzt pflegen die Entwickler von Ceylon einen offenen Umgang mit der Community und jeder der Interesse zeigt, kann seine Ideen in Diskussionen einbringen, oder gar selbst Hand an den Code von Ceylon legen.

Fazit

Die meisten der Vorträge, die ich besucht habe, waren sehr anregend und warteten mit neuen Ideen auf, die ich sicherlich in der nächsten Zeit ausprobieren werde. Insbesondere die Riege der neu vorgestellten JVM-Sprachen ist mit Kotlin und Ceylon interessant besetzt, auch wenn bei den meisten Vertretern noch unklar ist, in welcher Art und Weise man sie im Projektalltag einsetzen würde. Durch die Entwicklung neuer Sprachen bietet sich die Möglichkeit, verschiedene Ansätze zu kombinieren und zu erproben. Allein hierdurch erhält man wertvolle Informationen und entsprechende Wegweiser, die ebenso die Weiterentwicklung bereits bestehender Sprachen – z. B. Java – bestimmen können. Nicht zuletzt fördert der Umgang mit neuen Ideen und Problemlösungsansätzen die methodische Kompetenz des Entwicklers. Es ist also definitiv kein fruchtloses Unterfangen, sich mit neuen Sprachen zu beschäftigen, auch wenn man derzeit aufgrund der Vielzahl leicht den Überblick verlieren kann.

Tim Bray hat es in seiner Android Keynote bereits gesagt und der Trend ist natürlich spürbar: Die Nachfrage nach Applikationen für mobile Endgeräte wird weiter steigen. Bereits jetzt beherbergt der Android Marketplace mehr als 300.000 Anwendungen und um aus dieser Masse an Software hervorzustechen, muss man ein herausragendes Produkt abliefern. Tim Bray hob dabei insbesondere die Rolle des Designers hervor, der ganz einfach eine andere Sicht auf Oberflächengestaltung und Usability hat, als der Entwickler. Des Weiteren nehmen die technischen Kapazitäten von mobilen Endgeräten weiterhin zu. Der Markt bietet in absehbarer Zeit bereits Geräte mit Quad-Core-CPUs und dedizierten GPUs an, so dass Themen wie Nebenläufigkeit und Parallelisierung auch auf mobilen Geräten eine Rolle spielen werden.

Web-Application-Frameworks wie Play und Vaadin erfreuen sich zu Recht einer hohen Beliebtheit. Beide zeichnen sich durch hohe Produktivität aus. Während Play ein vielschichtiges Ökosystem bietet, ist bei Vaadin insbesondere die Kombination mit Activiti, einem Werkzeug zur Abbildung von Geschäftsprozessen, interessant. Durch die Integration der beiden Produkte ist es möglich, die Behandlung von Geschäftsprozessen über eine Web-Applikation abzubilden, ohne dabei auf die Möglichkeiten eines ausgereiften Modellierungswerkzeugs zu verzichten.

Insgesamt kann man die Konferenz nur empfehlen. Interessierte, die es zur Konferenz nicht geschafft haben, können voraussichtlich gegen Ende des Jahres über die e-Learning-Plattform www.parleys.com Aufzeichnungen der Vorträge ansehen.

von Markus Günther. Markus arbeitet seit März 2011 als Software Ingenieur bei der Accelerated Solutions GmbH und beschäftigt sich dort u. a. mit der Entwicklung von Java-basierten Systemen.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>