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

Österreich € 10,80 Schweiz sFr 19,50 Luxemburg € 11,15Deutschland € 9,80Java

Mag

1.2014

Neo4j-Tutorial: Graphdatenbanken zum Anfassen 82

Mehr TheMen: Java ME 8 und Embedded: Back to the Roots 106 | FX Traits: JavaFX und

Scala Traits kombiniert 90 | Sencha trifft REST: Mobile HTML5-Apps auf Knopfdruck 101

Java EE und der ACC Der unbekannte Dritte 45

Spring IOElasticsearch Suche mit anderen Augen 69

Alle Infos hier im Heft!

22

© iS

tock

phot

o.co

m/_

Rik

e_

Spring mit neuem Look und neuem Feel? 32

IDE-Integration mit der Spring Tool Suite 38

Spring Boot: New Kid on the Stack 42

Die Zukunft des Frühlings

Java Magazin 1.2014

Spring IO

Elasticsearch OSGi

Neo4j-Tutorial Application Client Container

Java ME 8

FX Traits

Mobile App Testingin the Cloud

30 days free trial!

Visit our website or call uswww.testobject.com+49 (0) 3302/559375

• Web service pushing your CI process forward

• No modifi cation required

easyon-demand

automated

• Save up to 90% of your testing time & budget

• CI server Plug-Ins

Find bugs before your users do! Try now!

javamagazin 1 | 201432 www.JAXenter.de

Titelthema Spring IO

Was es mit der neuen Plattform auf sich hat

Die Zukunft des Frühlings

Auf der diesjährigen SpringOne-Konferenz in Santa Clara kündigte

das Spring-Team die Plattform Spring IO an, einen komplett neuen

Ansatz, die Spring-Technologien zu nutzen. Wir werfen einen Blick

auf die Plattform und erläutern, was genau dahintersteckt.

von Oliver Gierke

© iS

tock

phot

o.co

m/_

Rik

e_

javamagazin 1 | 2014

TitelthemaSpring IO

33www.JAXenter.de

Spring ist wohl das populärste und am weitesten verbrei-tete Framework zur Entwicklung von Unternehmensan-wendungen in Java. Eine Vielzahl völlig verschiedener Anwendungstypen wird auf ihm implementiert: Einfa-che Webapplikationen, anspruchsvolle Serverapplikati-onen, aber auch Batchprozesse und Software im Bereich der Applikationsintegration gehören zum klassischen Einsatzfeld des Frameworks. Unbestreitbar ist auch der hohe Einfluss in Spezifikationen für Dependency Injec-tion wie in Java EE 5. Auch neuere Spezifikationen wie JTA 2.1 (JSR 907 – @Transactional) und JSR 352 für Batchapplikationen in Java tragen eindeutig die Hand-schrift der entsprechenden APIs und Module des Spring Frameworks.

Die technischen Anforderungen an Softwaresysteme haben sich in den letzten Jahren allerdings auch stark verändert. Während es vor fünf Jahren vielleicht noch genügte, mit einer relationalen Datenbank zu spre-chen und in ihr enthaltene Daten in einer Webansicht anzuzeigen, trifft man heutzutage nicht selten auf eine Kombination aus relationalen und nicht relationalen Datenbanken, der Anforderung zu OAuth-Security, der Integration mit sozialen Netzwerken oder dem Bearbei-ten von extrem großen Datenbeständen, zeitkritischen Daten usw. Auch für diese Herausforderungen bietet Spring Unterstützung an.

Schon immer bestand das Spring-Ökosystem aus ver-schiedenen Modulen, die den Aspekten der unterschied-lichen Applikationstypen Rechnung trugen. Der Vorteil hierbei besteht darin, dass eine Applikation exakt die Teile von Spring benutzt, die sie benötigt. Umgekehrt sorgt das konsistente Programmiermodel der einzelnen Module dafür, dass die Einarbeitungszeit in einen bisher unbekannten Teil des Ökosystems überschaubar bleibt – sich Entwickler schnell zu Hause fühlen, auch wenn man sich in technisch neues Terrain begibt.

Ein gutes Beispiel hierfür ist die Repository-Abstrak-tion der Spring Data Module: hat man sich zum Beispiel einmal im Bereich JPA daran gewöhnt, in dieser Her-angehensweise Datenzugriff zu implementieren, ist der Umstieg auf einen MongoDB-basierten Datenzugriff mit gleicher Technologie sehr einfach. Es wird Entwicklern also sehr leicht gemacht, einmal erworbenes Wissen in andere Kontexte zu übertragen.

HerausforderungenDer modulare Aufbau des Frameworks erlaubt es den Einzelprojekten, sich in unterschiedlicher Geschwin-digkeit zu bewegen, andere Releasezyklen zu wählen. Während das Spring Framework seit mehreren Jah-ren kontinuierlich auf einem Ein-Jahres-Rhythmus für Majorversionen ist, bewegen sich z. B. die Spring Data Module in einem etwa sechs-monatigen Zyklus. Grund dafür sind unter anderem unterschiedliche Releasezyk-len der Dritttechnologien, die es zu integrieren gilt: Der Lebenszyklus einer Java-EE- oder JDK-Spezifikation, die Spring 4 sehr stark beeinflusst, unterscheidet sich von dem eines MongoDB-Treibers, der wiederum eine

wichtige Abhängigkeit des Spring Data MongoDB Mo-duls ist.

Die Konsequenz daraus ist die Notwendigkeit, Kom-patibilität zwischen den entsprechenden Modulen des Spring Frameworks sicherzustellen und es den Entwick-lern möglichst einfach zu machen, die Module in kom-patiblen Versionen zu konsumieren.

Die PlattformUm mehr Überblick über das Ökosystem zu geben, de-finiert die Spring-IO-Plattform den Teilbereich Founda-tion. Dieser Bereich illustriert die verfügbaren Spring Module und wie diese zueinander in Beziehung stehen und definiert so die Basistechnologien des Stacks. Im Bereich Core findet man wie erwartet das Kernframe-work, sowie die bekannten Technologien Spring Secu-rity und Groovy. Mit Spring 4 gibt es in diesen Tagen das erste Mal seit vier Jahren eine neue Majorversion des Kernframeworks. Enthalten sind die Unterstützung für Java 8, die wichtigsten Java-EE-7-APIs, WebSockets, Groovy-basierte Bean-Definitionen und ein überarbei-teter Dependency-Injection-Mechanismus mit Unter-stützung für Applikationskomponenten mit Generics. Neu in diesem Bereich ist sicher Project Reactor, ein Basisframework für Reactive Programming. Reactor ist eine Basistechnologie, die es erlaubt, hochperformante, eventbasierte Anwendungen zu implementieren.

Im Bereich der Persistenz erweitern vor allem die Spring-Data-Projekte den Funktionsumfang des Kern-frameworks. Im relationalen Bereich bieten die Modu-le für JPA und JDBC die umfassendste Unterstützung für Entwickler, möglichst effizient Datenzugriff zu implementieren. Im nicht relationalen Bereich gibt es hier Unterstützung für die Platzhirsche MongoDB, Neo4j und Gemfire. Besonders hier ist allerdings auch die Spring-Community sehr aktiv und bereichert das Portfolio durch Module für Couchbase, Solr und Elas-ticsearch.

Während die unteren zwei Layer unserer Architek-tur sehr universell einsetzbare Technologien beschrei-ben, ist der obere Teil der Foundation schon sehr an den verschiedenen Applikationstypen orientiert, die sich mit Spring implementieren lassen. Hierzu gehört zum Beispiel Spring Integration, eine Implementierung der Enterprise Application Integration Patterns des gleich-namigen Buchs von Gregor Hohpe. Spring Batch war lange Zeit das einzig verfügbare Framework für die Implementierung von Batchszenarien und wird in der kommenden Version 3.0 aufgrund seiner Reife wohl die wichtigste Implementierung des JSR-352-Standards.

Im Bereich der Big-Data-Applikationen hat sich in der Java-Welt vor allem Spring Hadoop einen Na-men gemacht, da es Apache Hadoop konsistent in eine Spring-Applikation einfügt und Entwicklern gewohn-te Programmiermodelle bereitstellt. Im Bereich Web sind die altbekannten Module Spring MVC und Spring WebFlow zu finden, sowie Unterstützung für Legacy-Technologien wie SOAP (durch Spring Web Services)

javamagazin 1 | 2014

Titelthema Spring IO

34 www.JAXenter.de

aber auch unentdecktere Aspekte wie Hypermedia im Bereich REST Web Services (durch Spring HATEOAS).

IO ExecutionAuf den Bereich der Foundation setzt nun der Execution-Bereich auf. Wie der Name schon vermuten lässt, finden sich hier Laufzeitumgebungen, die zum Teil nicht mehr einfach Bibliotheken sind, sondern Ausführungs-Con-tainer für Applikationen einer bestimmten Klasse. Das Spring-Team spricht hier von Domain-specific Runtimes (DSRs), wobei Domäne hier noch den technischen Be-reich beschreibt, in den sich die Applikation einordnet.

Die klassischste und wohl auch bekannteste Ausfüh-rung solch einer Laufzeitumgebung ist Grails. Es hilft Entwicklern, sehr schnell und produktiv Groovy-basier-te Webapplikationen zu bauen, in dem es Projektstruk-

tur vorgibt, und auch zur Laufzeit den Applikationen Funktionalität beisteuert. Spring XD ist noch ein sehr junges Projekt, das sich dem Bereich Big Data Proces-sing annimmt und – ähnlich wie Grails – die für die Pro-blemlösung relevanten Spring-Technologien bündelt und zusätzlichen Mehrwert in Bezug auf Monitoring und Operations bietet. Eine Vorstellung von Spring XD findet sich unter [1].

Ein ebenfalls neues Projekt im Portfolio ist Spring Boot, entstanden aus verschiedenen Ideen der letztjähri-gen SpringOne 2012. Eberhard Wolff und Martin Lip-pert gehen im Folgenden detailliert auf Spring Boot ein, daher hier nur ein paar erste Informationen.

Spring BootSpring Boot ist ein sehr zentraler Bestandteil der Spring-IO-Plattform. Das Projekt geht drei wesentli-che Aspekte der Anwendungsentwicklung bei Spring-Applikationen an:

1. Vereinfachtes Dependency Management2. Automatische Defaults in der Anwendungskonfigu-

ration3. Vereinfachtes Deployment und Betrieb von Java-

Applikationen

Vereinfachtes Dependency ManagementWie oben bereits angesprochen, ist das Verwalten von Abhängigkeiten eine kritische Aufgabe in Soft-wareprojekten. Im Spring-Umfeld ist es die Aufgabe der Entwickler und Architekten zu definieren, welche Abhängigkeiten ein System benötigt und in welcher Version diese benutzt werden sollen. In alternativen An-sätzen – zum Beispiel einem Java EE Application Ser-ver – scheint diese Herausforderung nicht zu bestehen, da dieser bereits vordefinierte Implementierungen der jeweiligen Spezifikationen mit ausliefert. Was auf den ersten Blick eine einfache Lösung zu sein scheint, hat allerdings auch gravierende Nachteile.

Erstens wählt der Serverhersteller die Bibliotheken aus, nicht das Team selbst. Die Auswahl ist also nicht unbedingt von den Anforderungen im Projekt getrieben („Kann der JPA-Provider überhaupt mit einem Daten-bankschema umgehen, das wir nutzen müssen?“), son-dern von in Bezug auf das Projekt recht willkürlichen Anforderungen. Zweitens stellt sich die Herausforderung der manuellen Abhängigkeitsverwaltung in Projekten so-wieso, sobald dieses nicht standardisierte Bibliotheken einsetzt und sie als direkte Abhängigkeiten verwendet.

Drittens ist man in diesem Modell mit seinen Applika-tionen sehr stark an den Lebenszyklus der Deployment-Plattform gebunden. Stolpert man z. B. über einen Bug in einer im Server betriebenen Bibliothek, ist es unter Um-ständen nicht ohne Weiteres möglich, eine neuere Versi-on dieser Bibliothek zu verwenden, die den Bugfix evtl. schon enthält. Der lange Lebenszyklus der Plattform hat weiterhin den Nachteil, dass eben Upgrades derselben nur nach sehr langen Zeiträumen möglich sind bzw.

Interview mit Jürgen Höller

Auf der W-JAX 2013 traf Claudia Fröhling auf Jürgen Höller, um über die neue Plattform, das anstehende Spring-Frame-work-Release und die Chancen von Java 8 zu sprechen. http://bit.ly/1dkmjG1

Abb. 1: Spring IO Platform Stack

www.JAXenter.de

durchgeführt werden. Für den im Frühjahr verabschiedeten Java-EE-7-Standard gibt es von den großen Herstellern leider auch über ein halbes Jahr später noch immer keine offi-ziell unterstützte Serverversion.

Im Umfeld von Spring-Applikationen ist es also üblich, den exakt anderen Weg zu ge-hen: die toolgestützte, manuelle Verwaltung von Abhängigkeiten und deren Versionen sowie das Deployment eben dieser als JARs im Applikationsartefakt. Auch dies ist natür-lich nicht ohne Herausforderungen: Beson-ders das Zusammensuchen von kompatiblen Versionen hat so manchem Entwickler und Architekten das ein oder andere graue Haar beschert.

Spring Boot geht dieses Thema an, in dem es einen wohldefinierten Satz an Abhängig-keiten und deren Versionen definiert und diese Definition über bekannte Dependency-Management-Werkzeuge wie Maven oder Gradle anbietet. Im Falle von Maven ge-schieht dies über ein Parent-POM, das die Versionsnummern der unterstützten Abhän-gigkeiten im <properties />- und <dependen-cyManagement />-Block definiert.

Um nun Abhängigkeiten zu konsumieren, kann man diese jeweils selbst definieren, al-lerdings ohne die Versionsnummern explizit anzugeben. Da in vielen Fällen aber gleich ganze Sätze an Abhängigkeiten benötigt werden – zum Beispiel Spring Data JPA mit Hibernate – bietet Boot so genannte Starter-POMs an, die für einen bestimmten Techno-logiebereich Abhängigkeitssätze definieren. Das eben bereits angesprochene Starter-POM spring-boot-starter-data-jpa deklariert Abhängigkeiten zu Spring Data JPA, Hiber-nate, dem Spring-ORM-Modul und dem Starter-POM für JDBC. Dies wiederum bein-haltet das Spring-JDBC-Modul und eine Ab-hängigkeit zum Tomcat Connection Pool. So bekommt man durch die Deklaration einer einzigen Abhängigkeit einen kompletten Satz an Dependencies in kompatiblen Versionen.

Dadurch, dass die Versionen der individu-ellen Abhängigkeiten als Maven- bzw. Grad-le-Properties definiert sind, ist es allerdings auch möglich, Versionen für bestimmte Dependencies manuell zu definieren und so im Falle eines wichtigen Bugfix-Releases die funktionierende Version zu beziehen. Ver-sionsupgrades von Abhängigkeiten liegen also immer noch im Verantwortungsbereich des Entwicklerteams, können z. B. auf eine Spring-IO-Version standardisiert werden, um so das benötigte Maß an Konsistenz zwi-schen Applikationen herzustellen.

Defaults in der AnwendungskonfigurationKommen wir noch einmal zurück zum Bei-spiel Spring Data JPA. Durch die Dekla-ration des entsprechenden Starter-POMs können wie oben beschrieben auf einen Schlag die benötigten Abhängigkeiten (das JPA API Jar, Hibernate als Persistenzprovi-der und Spring Data JPA als Hilfsbibliothek) konsumiert werden. Nun ist es jedoch immer noch nötig, ein gewisses Konfigurationssetup zu definieren, um Spring die entsprechenden Komponenten instanziieren zu lassen. In un-serem konkreten Fall wäre das Folgendes:

•Eine DataSource mit den entsprechenden Verbindungsdaten zum Datenbankserver

•Eine LocalContainerEntityManagerFacto-ryBean, um JPA zu initialisieren

•Einen JpaTransactionManager für das Transaktionsmanagement in den Spring Data JPA Repositories

•Ein @EnableJpaRepositories, um das Auffinden von Spring Data Repository Interfaces und die Erzeugung der entspre-chenden Spring Beans zu aktivieren

Unabhängig davon, wie die Repository-Interfaces eigentlich aussehen, welche Da-ten persistiert werden, ist also ein gewisses Grundrauschen an Konfiguration notwen-dig, die sich die meisten Entwickler aus an-deren Projekten oder Beispielen, die sie im Netz finden, zusammensuchen müssen.

Spring Boot stellt nun mit seinem Auto-konfigurationsmodul einen Mechanismus zur Verfügung, der dieses Vorgehen sehr stark vereinfacht. Durch @EnableAutoCon-figuration an einer Konfigurationsklasse in-spiziert Boot den Classpath der Applikation und erzeugt eine wohldefinierte Menge von Default-Konfiguration, es sei denn, es sind für die zu registrierenden Komponenten bereits manuelle Bean-Definitionen vorhan-den. In unserem Beispiel genügt also diese Konfigurationsklasse

@Configuration@EnableAutoConfiguration@ComponentScanclass Application { ... }

um die Spring-Data-JPA-Konfiguration wie oben beschrieben zu defaulten. Hierbei wird sehr stark damit gearbeitet, feststellen zu können, welche Bibliotheken im Applika-tions-Classpath vorhanden sind. Das Vor-handensein von H2 oder HSQLDB sorgt zum Beispiel für die automatische Registrierung

Anzeige

javamagazin 1 | 2014

Titelthema Spring IO

36 www.JAXenter.de

einer In-Memory-DataSource über die Mechanismen, die Spring über den EmbeddedDatabaseBuilder bereit-stellt. Dadurch, dass das Hibernate EntityManager JAR im Classpath liegt, wird eine LocalContainerEntityMa-nagerFactory deklariert und ein JpaTransactionMana-ger. Das Scannen nach Spring Data JPA Repositories wird vom Vorhandensein des Spring Data JPA JARs ausgelöst usw.

Dieser Mechanismus ist eigentlich eine Umsetzung des bekannten Convention-Over-Configuration-Mechanis-mus. Das heißt, man schreibt nur die Konfiguration, die explizit von den Defaults abweicht. Um dies zu tun, gibt es zwei Möglichkeiten: Konfigurationsdetails, die sich sehr wahrscheinlich von Applikation zu Applikation un-terscheiden werden, kann man über ein Properties-File namens application.properties im Classpath bzw. dem Ausführungsverzeichnis anpassen oder über JVM-Para-meter definieren. Klassiker hierbei sind Informationen wie der JDBC-URL der Datenbank, Benutzername und Passwort usw.

Um jedoch auf weitergehende, explizite Konfiguration eingehen zu können, registriert Boot die Default-Bean-Definitionen nur, wenn nicht bereits eine Bean-Defini-

Listing 1

@Configuration@EnableAutoConfiguration@ComponentScanclass Application {

@Bean public DataSource dataSource() { // Explizite Deklaration hier }}

Listing 2

@Configuration@EnableAutoConfiguration@ComponentScanclass Application {

public static void main(String... args) { SpringApplication.run(Application.class, args); }}

tion des entsprechenden Typs vorhanden ist. Um zum Beispiel die DataSource komplett anders zu konfigurie-ren als im Default, genügt es, eine entsprechende Bean-Definition zu deklarieren (Listing 1).

Für diese Datei konfiguriert Boot die gleichen Defaults wie oben beschrieben, nutzt aber die hier explizit dekla-rierte DataSource. Auf diese Weise zieht sich Boot für manuell konfigurierte Bean-Definitionen diskret zurück und nutzt diese transparent für seine weitere Arbeit.

Vereinfachter Betrieb von Java-ApplikationenTraditionell werden Java-Webanwendungen in einem Server betrieben. Dies kann sowohl ein einfacher Servlet Container wie Tomcat sein, aber auch ein größerer Ap-plication Server, der neben einer Servlet-Umgebung noch weitere Dienste zur Verfügung stellt. Theoretisch sieht das Nutzungsmodell dieser Server vor, mehrere Applika-tionen in eine Serverinstanz zu deployen, um Ressourcen wie Connection-Pools zentral verwalten zu können.

In vielen Fällen wird heutzutage jedoch jeweils eine ein-zelne Applikation in eine einzelne Serverinstanz deployt. Dies ist vor allem der Fall, da das gemeinsame Deployment von Applikationen diese indirekt über die Infrastruktur aneinander koppelt. Muss der Server zum Beispiel für ein Upgrade heruntergefahren werden, betrifft das immer alle Applikationen, die in ihm deployt sind. Sorgt eine Appli-kation im Server für ein Speicherleck, betrifft das unter Umständen auch die anderen Applikationen.

Ein alternativer Ansatz, der mehr und mehr Verbrei-tung findet, ist es, die benötigten Serverkomponenten mit der Applikation zu bündeln und auch mit ihr zu starten. Im Zusammenhang mit den oben beschriebenen Me-chanismen zum Dependency Management und den ent-sprechenden Defaults bezüglich der Konfiguration bietet Spring Boot einen zweistufigen Mechanismus, um dieses Embedded-Server-Modell zu betreiben (Listing 2).

Man kann eine Spring-Boot-basierte Applikation starten, indem man sich über den bereits beschriebenen Mechanismus zum Beispiel Tomcat oder Jetty in den Classpath holt und eine Java-Klasse mit einer main(…)-Methode deklariert, die per statischem Aufruf Spring-Application die Konfigurationsklasse (hier ein und dieselbe Klasse) übergibt. Boot findet die Serverkompo-nenten sowie Spring MVC im Classpath, leitet daraus die Notwendigkeit des Serverstarts ab und sorgt selbststän-dig für das Hochfahren des Servers. Oft anzupassende Konfigurationswerte – zum Beispiel der Serverport oder der Kontextpfad der Applikation – können wie oben be-reits beschrieben über die application.properties-Datei oder JVM-Parameter überschrieben werden.

Um die Applikation einfach starten zu können, ist es notwendig, ein JAR zu erzeugen, das alle Abhängig-keiten enthält. Hierzu kann ein Maven- bzw. Gradle-Plug-in verwendet werden. Bevorzugt man weiterhin das Deployment in einen Application Server, so genügt es, das Projekt als WAR-Projekt zu definieren. Das Spring-Boot-Maven- bzw. -Gradle-Plug-in sorgt dann beim Build automatisch dafür, dass neben der norma-

Das erste offizielle Release der Spring-IO-Plattform ist für das

erste Quartal 2014 geplant.

TitelthemaSpring IO

len WAR-Datei auch ein startbares WAR erzeugt wird. Zum Start der Applikation ruft man nach erfolgreichem Build einfach java -jar target/*.(jar|war). Zur Entwick-lungszeit in der IDE genügt natürlich das Starten der Klasse mit der oben beschriebenen main(…)-Methode.

Monitoring und OperationsEin oft genutztes Feature traditioneller Server ist die Möglichkeit, den Zustand der Applikation über Metri-ken beurteilen zu können bzw. sogar bestimmte Werte zur Rekonfiguration zur Laufzeit z. B. per JMX zu expor-tieren. Spring Boot stellt so genannte Actuator bereit, die mit der Applikation deployt werden können. Diese stellen dann ähnliche Funktionalität zur Verfügung, in dem sie Out of the Box ein paar HTTP-Ressourcen veröffentli-chen, die vielseitige Informationen per JSON exponieren:

•/env – die Properties der Ablaufumgebung (JVM-Argumente, System-Properties, die Systemumgebung)

•/health – ein einfaches OK, wenn die Anwendung gestartet werden konnte

•/info – spezielle Properties unter dem Schlüssel end-points.info.$key; hier können z. B. Informationen wie die Applikationsversion einfach hinterlegt werden

•/metrics – Basismetriken der Applikation (Speicher-verbrauch, Counter der HTTP-Statuscodes usw.)

•/trace – Informationen über die letzten 100 Anfragen an die Applikationen (HTTP-Request-URL, Header, Response usw.)

•/dump – ein Threaddump der Applikation•/beans – eine Liste aller Spring Beans der Applikation

Getting Started GuidesEin weiterer, lose mit Spring IO verbundener Aspekt der Plattform sind die komplett überarbeiteten Getting Start ed Guides, die auf http://spring.io zu finden sind. Die große Popularität des Spring Frameworks sorgte

Anzeige

über die Jahre für eine Vielzahl verschiedenster Tuto-rials, die im Netz zu finden sind. Nachteil dieser Fülle ist, dass Entwickler, die heute nach Lösungen für ein bestimmtes Problem suchen, oft sehr alte – und damit auch oft veraltete – Informationen finden.

Die Getting Started Guides sind aufgabenbasiert, d. h. es steht nicht primär die verwendete Technologie im Vordergrund, sondern ein bestimmtes Ziel wie zum Beispiel das Persistieren von Daten in eine relationale Datenbank, das Veröffentlichen von Daten als HTTP-Ressourcen usw. Die Beispiele sind in ungefähr zehn Minuten durchzuarbeiten, nutzen Spring Boot und er-lauben dem Entwickler so, sich rasch in Spring und seine Ökosystemprojekte einzuarbeiten.

Zeitplan und AusblickDas erste offizielle Release der Spring-IO-Plattform ist für das erste Quartal 2014 geplant. Initial bestehen wird es aus einem wohldefinierten Set an zusammenarbeitenden Spring-Modulen und den entsprechenden Mechanismen, diese Module auf einfachste Weise zu konsumieren. Zu-sammen mit dem Kernframework in Version 4 bietet Spring eine zukunftsfähige Plattform für Java-basierte Unternehmensanwendungen im Jahre 2014.

Oliver Gierke ist Teil des Spring-Data-Teams bei SpringSource, a division of VMware, und leitet dort das JPA-, MongoDB- und Core-Modul. Seit über sechs Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mit-glied der JPA 2.1 Expert Group. Seine Arbeitsschwerpunkte liegen

im Bereich Softwarearchitektur, Spring und Persistenztechnologien. Er ist re-gelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln.

Links & Literatur

[1] http://jaxenter.de/artikel/Spring-XD-fuer-Big-Data

Anzeige