CD-INHALT

Alle CD-Infos ab Seite 3

HIGHLIGHTS

PrimeFaces 3.2Ceylon 0.2Tapestry 5.3.2

WEITERE INHALTE

• Accumulo 1.4.0• Jawr 3.3.3• TomEE 1.0.0-beta-2

JSF 2.0 in Liferay Portal

von Andy Bosch

Video von der JAX 2011

magazinJava • Architekturen • Web • Agile www.javamagazin.de

JAVA

Mag

Apache Tapestry: Skalierbare Webapplikationen entwickeln 46

6.2012M

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agM

agCDin

kl.

BPMN 2.0 und Java EE 6Workflows mit Activiti 100

E pluribus JVMCompilerbau entmystifiziert 23

Tutorial Continuous DeliveryIm Maschinenraum 69

Java versus CeylonEine neue Sprache für die JVM 18

DeltaSpikeVereinigung der CDI-Communitys 85

Scala und Spring im TandemA Match made in Heaven 95

Was Sie von der neuen Version erwarten können 28

Interview mit Spec Lead Ed Burns 34

JSF und Webperformance 36

JSF 2.2HIGHLIGHTS

PrimeFaces 3.2Ceylon 0.2Tapestry 5.3.2

WEITERE INHALTE

Was Sie von der neuen Version erwarten können 28

Interview mit Spec Lead Ed Burns 34

JSF und Webperformance 36

Sonderdruck fürwww.codecentric.de

2 www.JAXenter.dejavamagazin 6 | 2012

Sonderdruck

© Software & Support Media GmbH

von Frank Hinkel und Muhammet Altindal

Neben der Sprache Java existiert eine Vielzahl weiterer Programmiersprachen, die die Java Virtual Maschine (JVM) als Laufzeitumgebung verwenden. Ceylon ist eine davon. Ebenso wie bei der Java-Sprache wird der Quell-code von Ceylon in Bytecode umgewandelt, der von der JVM interpretiert werden kann. Ceylon ist eine neue ob-jektorientierte Programmiersprache, die eine Reihe von funktionalen Aspekten beinhaltet. Die polarisierenden und hoch gesteckten Ziele hat sie in die Medien der IT katapultiert. Dabei soll Ceylon ausdrucksstärker, stabiler und einfacherer als Java sein. Obwohl sie sich aktuell in der Entwicklung befindet, sorgt die Sprache bereits jetzt für heiße Diskussionen: Eine Umfrage auf JAXenter.de hat ergeben, dass die Community die Notwendigkeit und den Nutzen einer weiteren Sprache anzweifelt [1]. Das mag vor allem an der Situation von Scala liegen, die zu-letzt harte Kritik einstecken musste. Dieser Artikel ver-sucht die Ideen von Ceylon beispielhaft zu transportieren und direkt mit den Merkmalen von Java zu vergleichen, um einen möglichen Mehrwert transparent zu machen.

Stand der DingeNachdem Gavin King – die federführende Person von Hibernate und Seam – im 1. Quartal 2011 halbverse-hentlich die Existenz des Ceylon-Projekts bekannt gab, wurde Ende Dezember dann offiziell der erste Meilen-stein (Newton) erreicht und somit das erste Release ver-öffentlicht. Mit dem aktuellen Stand lassen sich bereits einfache Programme realisieren [2]. Empfehlenswert ist die Entwicklungsumgebung Eclipse, da hierfür ein funk-tionsfähiges Plug-in existiert [3].

Warum Ceylon?Auf der QCon in Beijing 2011 setzte sich Gavin King für seine neue Kreation ein und präsentierte die Gründe, die ihn zur Entwicklung von Ceylon bewegt haben und die Ziele, die er mit der Sprache verfolgt. Ihn stören vor al-lem schlechte Metaprogrammierung, fehlende funktionale Elemente und fehlende Modularisierung des Java SE SDK. Ebenfalls kritisiert er Arrays, primitive Datentypen, die ungeschickte Realisierung von Annotationen, die kaum erlernbaren Generics mit Wildcards und Rawtypes und andere sehr bizarre Phänomene wie beispielsweise die Tat-sache, dass alle Java-Objekte Semaphores sind. Diesem 15 Jahre alten Work-in-Progress-Feeling soll Ceylon ein Ende bereiten. Die obersten Ziele sind demnach: Eleganz, Les-barkeit, Typsicherheit und Metaprogrammierung.

ÜberblickUm die Elemente einer Sprache zu überschauen und ei-nen ersten Einblick in die Unterschiede beider Sprachen zu bekommen, ist es wichtig, das Typsystem von Java und Ceylon zu kennen (Abb. 1).

Auf Enums und primitive Datentypen verzichtet Cey-lon vollständig und erweitert das Typsystem um Union- und Intersection-Typen. Was das im Detail bedeutet, wird im späteren Vergleich deutlich. Neben dem Typsystem ist das Vererbungsmodell von zentraler Bedeutung (Abb. 2).

Die Vererbungsmodelle von Java und Ceylon decken sich weitestgehend. Ceylon unterstützt die enumerierten Subklassen, die im späteren Verlauf anhand von Beispie-len erläutert werden. Das letzte Übersichtskriterium, das beim Einstieg in Ceylon helfen kann und notwendig ist um die Listings besser zu verstehen, ist das Wörterbuch in Tabelle 1.

Eine neue Sprache für die JVM

Kaffee gegen Tee: Java versus Ceylon

„Say more, more clearly“: Dieses Motto haben sich Ceylon-Entwickler auf die Fahnen geschrieben. In diesem Artikel wird unter-sucht, mit welchen Zutaten der hausgemachte Tee Gavin Kings gebraut wird – und ob Ceylon das Zeug dazu hat, dem weltweit geliebten Kaffee von Oracle in absehbarer Zukunft Paroli zu bieten.

3www.JAXenter.de javamagazin 6 | 2012

Sonderdruck

© Software & Support Media GmbH

Vergleich von Java und CeylonZwar inspirierte Java die Gestaltung von Ceylon über-wiegend, jedoch sind auch Inhalte anderer objektorien-tierter und funktionaler Sprachen mit eingeflossen. Um die konkreten Inhalte und Unterschiede transparent zu machen, werden die Inhalte von Ceylon in drei Katego-rien betrachtet:

1. Neue Inhalte (nicht vorhanden in Java)2. Ausgetauschte Inhalte (in Ceylon ersetzt)3. Entfernte Inhalte (nicht vorhanden in Ceylon)

Neue Inhalte von CeylonHigh-Order Functions: Als „High-Order Functions“ werden Funktionen bezeichnet, die andere Funktionen als Parameterargumente akzeptieren oder diese als Er-gebnis zurückliefern. Das ermöglicht funktionale Pro-grammierung in Ceylon. Diese Technik ist Grundlage für eine ausgefeilte Closure-Verwendung und zentrale Komponente von Ceylon. Die Syntax von „High-Order Functions“ ist angelehnt an Smalltalk (Listing 1).

Polymorphe Operatoren: Jeder Operator ist für be-stimmte Datentypen definiert. Es gibt keine Unterstüt-zung für benutzerdefiniertes Überladen von Operatoren. Durch die Implementierung einer Schnittstelle für einen Operator kann die Anwendung des Operators für den implementierenden Typ gewährleistet werden (Listing 2).

Named Argument Syntax: Der Aufruf von Funktio-nen kann unter Nutzung der „Named Argument Syn-tax“ erfolgen. Diese Art von Funktionsaufrufen erhöht bei einer Parameterliste mit mehr als zwei bis drei Über-gabewerten die Übersichtlichkeit sowie die Lesbarkeit. Dies ist eine typsichere und deklarative Spracherweite-rung für die Initialisierung von Objekten und ermöglicht das einfache Erzeugen von Template-Funktionalitäten. Durch diese Syntax können hierarchisch strukturierte Daten wie beispielsweise Dokumente, Benutzerschnitt-stellen und Konfigurationen im Quellcode ausgedrückt werden. Damit bietet Ceylon eine weitere Möglichkeit auf XML als strukturiertes Datenformat zu verzichten und nähert sich bei der Initialisierung gängigen Daten-formaten wie JSON (Listing 3).Compilergeschützte Namenskonventionen: Ceylon kennt insgesamt drei Namensräume für Bezeichner und zwingt den Entwickler zur Einhaltung definierter Konventionen. Klassen, Interfaces und Typparame-ter müssen mit einem Großbuchstaben beginnen. At-tribute, Variablen und Methoden beginnen mit einem Kleinbuchstaben. Packages müssen vollständig aus Kleinbuchstaben bestehen (Listing 4).

Attribute – C#-Style Properties: Attribute stellen flexible Mechanismen für das Lesen und Schreiben von Werten in privaten Klassenfeldern dar. Mit Attributen werden Getter und Setter für Klassenfelder in Ceylon abgebildet. Diese werden in Ceylon auf drei verschiedene Arten deklariert: Simple, Getter, Setter. Attribut-Definitionen können von Subklassen überschrieben werden und unterstützen eine polymorphe Verwendung. Bei der Deklaration von Attri-

Listing 1

void repeat(Integer times, Callable<Void,Integer> perform) { for (i in 1..times) { perform(i); }}

Listing 2

shared class Dualzahl(String neueDualzahl) satisfies Summable<Dualzahl> { variable String dualzahl := neueDualzahl; // getter setter shared actual Dualzahl plus(Dualzahl other) { // Addition der Dualzahlen this.dualzahl return summand; }}// Beispiel Aufrufvariable Dualzahl d1 := Dualzahl("1010");variable Dualzahl d2 := Dualzahl("1100");d1 := d1 + d2;

Abb. 1: Typsysteme im Vergleich

Abb. 2: Verbungs-modelle im Vergleich

JavaLexikalischesElement

CeylonLexikalischesElement

implements Schlüsselwort satisfies Schlüsselwort

public Schlüsselwort shared (modul) Annotation

protected Schlüsselwort nicht vorhanden -

private Schlüsselwort (ohne Modifikator)

new Schlüsselwort nicht vorhanden -

final Schlüsselwort variable (Gegenteil) Annotation

abstract Schlüsselwort formal Annotation

@Override Annotation actual Annotation

instanceof Schlüsselwort is Schlüsselwort

null Schlüsselwort Nothing Klasse

Tabelle 1: Wörterbuch – Java, Ceylon

4 www.JAXenter.dejavamagazin 6 | 2012

Sonderdruck

© Software & Support Media GmbH

Listing 3

Html html { head = Head { title = "Titel der Website"; }; body = Body { content = Div { text = "Inhalt"; css = "meineCssKlasse"; }; };}

Listing 4

class MeineKlasse() {} // compile successclass meineKlasse() {} // compile errorclass Bruch() { Float zaehler; // compile success Float Nenner; // compile error}Package package { name='neuerPackage'; // Verstoß gegen Namenskonvention shared=true; // wird noch nicht vom compiler erkannt}

Listing 5

class Person(String neuerName) { variable String name := neuerName; // simple attribute shared String currentName { return name; } // attribute getter assign currentName { this.name := currentName; } // attribute setter}class Konfiguration() { // attribute getter mit named argument syntax shared Eintrag einstellung { id = "config1"; wert = "inhalt"; }}

Listing 6

// Verwendung von Intersection Type bei satisfiesclass MeineKlasse() satisfies Equality & Annotated {}// Verwendung von Union Type für die enumerierte Liste von Subtypeninterface Identity of Person | Organization {}// ...Integer|Float nummer = 3;if (is Equality&Integer nummer) { // Verarbeitung ...}

Listing 7

interface MeinInterface{}class MeineAbleitung() satisfies MeinInterface{ shared void sagHallo(){print("Hallo Welt!");}}class Umwandlung(MeinInterface wirdUmgewandelt){ if(is MeineAbleitung wirdUmgewandelt){ wirdUmgewandelt.sagHallo(); //zugriff auf SubMethode }}

buten werden diese auf Konsistenz geprüft. Der Compiler stellt sicher, dass Name und Typ eines definierten Attri-bute Setters deckungsgleich zu einem korrespondierenden Attribute Getter sind. Falls kein Simple Attribute dekla-riert wird, kann ein Attribute Getter auch mit der Named Argument Syntax deklariert werden (Listing 5).

Union und Intersection Types: Mit Union Types werden mehrere Typen aus verschiedenen Zweigen der Typhierarchie zu einem Typ zusammengeführt (Abb. 3 und 4). Der Union Type für die Typen A und B wird mit A | B beschrieben. Dabei sind die Typen A und B Subty-pen des Union Typs A | B. Zukünftig wird geplant, dass Ceylon Aliase für Union Types unterstützen soll. Inter-section Types bilden die Schnittstelle mehrerer Typen. Der Intersection Type für die Typen A und B wird mit A & B beschrieben (Listing 6).

Void und Bottom: Alle Typen sind Subtypen der Klas-se Void, die in dem Modul ceylon.language definiert wird. Das Attribut bottom vom Typ Bottom ist allen Typen zuweisbar. Die Instanziierung von Objekten die-ser Typen ist nicht möglich.

Ausgetauschte InhalteNeben den grundsätzlich neuen Inhalten hat Ceylon fol-gende bestehende Komponenten und Funktionalitäten von Java entfernt und durch andere ersetzt.

Keine expliziten C-ähnlichen Typecasts, sondern impli-zite blocklokale Umwandlung in Folge einer Prüfung bei den Schlüsselwörtern is, exists und nonempty (Listing 7).

Keine NullPointerException, sondern explizite Eingren-zung und korrespondierende Behandlung von Nullwer-ten. Bei der Deklaration von Variablen muss der Datentyp explizit nullwertfähig deklariert werden, falls dieser Null-werte beinhalten können soll. Das geschieht entweder über das „?“ hinter dem Datentyp oder als Union-Type-Deklaration. Der Zugriff auf einen solchen Datentyp muss über das Schlüsselwort exists geschützt werden, sodass zur Compile-Zeit lesende Zugriffe auf Nullwerte ausge-schlossen sind. In Ceylon sind NullPointerExceptions un-möglich. Ceylon realisiert dies intern über einen impliziten Cast von Nothing|String auf String, der durch das Schlüs-selwort exists ausgelöst wird (Listing 8).

Keine Überladung, sondern Default-Parameter, Union Types und Varargs. Ceylon möchte auf die wort-reichen Elemente von überladenen Methoden verzich-

5www.JAXenter.de javamagazin 6 | 2012

Sonderdruck

© Software & Support Media GmbH

ten. So können diverse überladene Methodensignaturen in Java durch eine einzige Methode in Ceylon abgebil-det werden (Listing 9).

Keine Konstruktoren, sondern Initialisierungspara-meter. Ein einziger Initialisierungsblock pro Klasse steht in Ceylon zur Verfügung. Ziel ist es, mehr Übersicht und Struktur in den einzelnen Klassen zu erzeugen. Ini-tialisierungsparameter werden dabei direkt in den Class Header geschrieben und können mit Default-Werten vorbelegt werden (Listing 9).

Keine „final“, sondern „variable“ Deklaration. In Ceylon sind alle Variablen standardmäßig konstant und können über den „=“ Operator initialisiert werden. Wenn echte nichtkonstante Variablen benötigt werden, muss dies explizit vor dem Datentypen annotiert wer-den. Außerdem erfolgt die Wertezuweisung ausschließ-lich über den „:=“ Operator (Listing 10).

Keine Arrays, sondern Sequences. Die Sequenzen von Ceylon verhalten sich ähnlich wie klassische Ar-rays, erlauben allerdings keine Manipulation der bein-halteten Elemente. Außerdem können Sequences nicht leer sein. Sie müssen mindestens ein Element beinhal-ten. Falls dennoch leere Sequences benötigt werden, kann dies über einen Union Type abgebildet werden: Empty|Sequence<String>. Die abgekürzte Schreibweise für diese Definition ist die bekannte Array-Deklaration: String[]. Beim Zugriff muss ähnlich wie bei Nullwerten vorher geprüft und implizit umgewandelt werden. Das geschieht in diesem Fall durch das Schlüsselwort non-empty. Sequences erlauben komfortable Listenoperati-onen (Listing 11).

Kein Reflection, sondern Metamodell. In Ceylon wird Metaprogrammierung anhand eines zur Compile-Zeit typsicheren Metamodells realisiert. Dies hat zur Folge, dass generische Zugriffe auf Attribute, Methoden und Klassen nicht durch diverse Checked Exceptions geprüft werden müssen. Die typischen Reflection Exceptions wie ClassNotFoundException, SecurityException, No-SuchMethodException etc. existieren in Ceylon nicht. Dies reduziert erheblich die Menge an Code – bestehend aus endlosen try-catch-Blöcken – und stabilisiert die Metaprogrammierung (Listing 12).

Keine Raw-Types und Wildcards, sondern Co- und Contravariant Type Parameter. Das „?“ und die fikti-ven Datentypen in generischen Parametern bereiten seit Java  5 den Entwicklern regelmäßig Kopfschmerzen. Ceylon räumt hier auf und macht „generics-related error messages [...] understandable to humans.“ [4] In diesem Zuge sind die Schlüsselwörter in und out zu verwenden, die den generischen Typ qualifizieren. in-Parameter dürfen ausschließlich in Argumentenlisten auftauchen, während out-Parameter nur als Rückgabetypen zu ver-wenden sind (Listing 13).

Entfernte InhalteNeben den ausgetauschten Inhalten wurden bei der Entwicklung von Ceylon auch einige komplett aus dem Sprachumfang entfernt:

•Primitive Datentypen existieren nicht in Ceylon. Alle Typen können in der Sprache selbst ausgedrückt werden. Deshalb sind alle Werte Instanzen der Klasse Void. Der Ceylon Compiler behält sich jedoch vor, aus Performancegründen Umwandlungen in primitive Datentypen der JVM vorzunehmen.

•Checked Exceptions sind nicht in das Fehlerbehand-lungsmodell von Ceylon eingeflossen. Dieses lehnt sich stark an Java an, schließt dabei aber grundsätz-lich „Checked Exceptions“ aus. Das hat zur Folge, dass es keine erzwungenen try-catch-Böcke gibt.

•Statische Variablen und Methoden wurden im Aufbau von Ceylon nicht berücksichtigt. Toplevel-Methoden und Attribute sind in Paketen deklariert und können dadurch direkt auf Paketebene verwendet werden. Dies führt zu einer einheitlichen modularen Struktur.

Abb. 3: Vertikale und horizontale Typkompa-tibilität

Abb. 4: Union und Intersec-tion Type

Listing 8

// Compileclean, Zugriffe durch "exists" geschütztshared String lese(String? wert, Nothing|String wert2, String wert3){ if (exists wert) { return wert; } if (exists wert2) { return wert2; } return wert3; }

Listing 9

class InitKlasse(Float version, String name = "Ceylon"){ InitKlasse k1 = InitKlasse(1.0); //varargs Style InitKlasse k2 = InitKlasse(9.0, "Java");}

6 www.JAXenter.dejavamagazin 6 | 2012

Sonderdruck

© Software & Support Media GmbH

•Synchronized-Methoden und -Blöcke sollen in Cey-lon zukünftig über Semaphores realisiert werden (Listing 14).

FazitBei der Analyse von Ceylon und entsprechenden Ent-wicklungsexperimenten ist uns aufgefallen, dass man sich als Java-Entwickler schnell zurechtfindet. Da die High-Order Functions, das Metamodell, die Callable-Komponenten sowie grundlegende Sprachmodule erst mit den kommenden Meilensteinen fertig gestellt wer-den, stößt man bei der Entwicklung mit Ceylon schnell an Grenzen. In diesem Rahmen sind uns die vereinfachte Initialisierung und die Union Types positiv aufgefallen. Deren zusätzlicher horizontaler Polymorphie-Zweig er-möglicht beispielsweise die „Empty“- und „Nothing“-Erweiterung an Deklarationen, die zur flexiblen Nullwertsicherheit führt. Die Metaprogrammierung wird erst mit Meilenstein 5 zur Verfügung stehen, wirkt auf uns allerdings sehr vielversprechend [5]. Daneben gibt es ein weiteres Entwicklungsprojekt Ceylon-JS, das Ceylon-Code zu JavaScript kompiliert. Die funktiona-len Komponenten sowie die Konzepte der „Structured Data“ von Ceylon sind auf diesen Anwendungsfall aus-gerichtet. Natürlich muss Ceylon als Angreifer unserer geliebten Java-Sprache Kritik einstecken und einen lan-gen Weg gehen, bevor man von einem wirklichen „Java Killer“ wird sprechen können. Wir sehen große Stärken in generischen Entwicklungsbereichen und könnten uns vorstellen, dass Ceylon dort tendenziell leichter begrün-dete Anwendungsfälle findet. Ceylon punktet besonders in den Bereichen Typsicherheit und beeindruckt durch lesbaren, schlanken, aber ausdrucksstarken Code. Es bleibt dabei aber sehr flexibel. Das Motto von Ceylon, „Say more, more clearly“, wird unserer Ansicht nach deutlich erkennbar gelebt. Wir empfehlen also jedem Java-Fan, auch mal eine Runde Tee zu genießen [6].

Frank Hinkel arbeitet in der Softwarearchitektur der Provinzial Rheinland Versicherung AG und entwickelt für das interne Web- und SOA-Framework. Seine Schwerpunkte sind die Spring-Integ-ration und das Bereitstellen einer Infrastruktur für die Realisierung komplexer Geschäftslogik in Java.

Muhammet Altindal arbeitet bei der codecentric AG und realisiert derzeit ein zentrales CRM-System. Seine Schwerpunkte sind die Entwicklung von RIAs unter Verwendung der Technologien SmartGWT und Vaadin.

Links & Literatur

[1] http://it-republik.de/jaxenter/quickvote/results/1/poll/135

[2] http://ceylon-lang.org/download/

[3] http://ceylon-lang.org/documentation/ide/

[4] http://ceylon-lang.org/documentation/spec/pdf/ceylon-language-specification.pdf

[5] http://ceylon-lang.org/documentation/roadmap/

[6] http://ceylon-lang.org/documentation/introduction/

Listing 11

class MeineSequenzen(){

String[] leer1 = {};

Empty|Sequence<String> leer2 = {};

variable Sequence<String> nichtLeer := {"Hallo"};

//merkwürdige Präzedenz: && höher als nonempty

if((nonempty leer1) && (nonempty leer2)){

nichtLeer := leer1 + leer2; // Verknüpfung erst ab milestone 3

}

}

Listing 12

// Konzeptbeispiel, wird in Milestone 5 umgesetzt

class MeinMeta(){

Type<List<String>> stringListType = List<String>;

Class<Person,Name> personClass = Person;

Method<Log, Void, String> infoMethod = Log.info;

Method<String, Boolean, String> smaller = Comparable<String>.

smallerThan;

}

Listing 13

interface Producer<in Input, out Value> {

shared formal Value produce(Input input);

}

class FensterProducer() satisfies Producer<Material, Fenster> {

shared actual Fenster produce(Material input) {

return Fenster(input);

}

}

Listing 14

try (semaphore) {

if (!map.defines(key)) {

map[key] := item;

}

}

Listing 10

class Variablen(){

String konstante = "fix";

variable String aenderbar := "ersetzen";

konstante = "fehler"; //Compile Error

aenderbar := "ok";

}