Spring Boot E-Book

Mark Heckler

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 379

Beschreibung

Leistungsstarke, produktionsreife Cloud-native Anwendungen mit dem beliebten Framework

• Erfahren Sie, wie Spring Boot die Entwicklung, die Konfiguation und das Deployment von Cloud-nativen Applikationen entscheidend vereinfacht
• Das Buch zeigt Ihnen, wie Sie direkt produktiv in die Arbeit mit Spring Boot einsteigen
• Für Java- und Kotlin-Entwickler:innen

Mit über 75 Millionen Downloads pro Monat ist Spring Boot das populärste und am weitesten verbreitete Java-Framework. Seine Benutzerfreundlichkeit und Leistungsfähigkeit haben die Anwendungsentwicklung von Monolith-Architekturen und Microservices revolutioniert. Doch die Einfachheit von Spring Boot kann auch verwirrend sein. Was brauchen Entwickler, um sofort produktiv zu werden? Dieses praxisorientierte Buch zeigt Ihnen, wie Sie das Framework nutzen, um erfolgreiche unternehmenskritische Applikationen zu entwickeln. Mark Heckler von VMware, der Firma hinter Spring, führt Sie durch die Architektur und die Konzepte von Spring Boot und behandelt auch Themen wie Debugging, Testen und Deployment. Wenn Sie mit Spring Boot schnell und effektiv Cloud-native Java- oder Kotlin-Anwendungen entwickeln wollen - inklusive reaktiver Programmierung, dem Erstellen von APIs und dem Einrichten von Datenbankzugriffen aller Art - dann ist dieses Buch genau das Richtige für Sie.

Leseprobe

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

Spring Boot

Cloud-native Anwendungen mitJava und Kotlin erstellen

Mark Heckler

Deutsche Übersetzung vonKathrin Lichtenberg

Mark Heckler

Lektorat: Alexandra Follenius

Übersetzung: Kathrin Lichtenberg

Korrektorat: Claudia Lötschert, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print978-3-96009-176-9

PDF978-3-96010-604-3

ePub978-3-96010-605-0

mobi978-3-96010-606-7

1. Auflage 2022

Translation Copyright für die deutschsprachige Ausgabe © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Spring Boot: Up and Running, ISBN 9781492076988 © 2021 Mark Heckler. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhalt

Vorwort

1Spring Boot in a Nutshell

Die drei Grundeigenschaften von Spring Boot

Starter für vereinfachtes Abhängigkeitsmanagement

Ausführbare JARs für ein vereinfachtes Deployment

Autokonfiguration

Zusammenfassung

2Ihre Werkzeuge auswählen und beginnen

Maven oder Gradle?

Apache Maven

Gradle

Die Wahl zwischen Maven und Gradle

Java oder Kotlin?

Java

Kotlin

Zwischen Java und Kotlin wählen

Eine Version von Spring Boot wählen

Der Spring Initializr

Rauf auf die Kommandozeile

In Integrated Development Environments (IDEs) bleiben

Unterwegs in main()

Zusammenfassung

3Ihr erstes Spring-Boot-REST-API erstellen

Das Wie und Warum von APIs

Was ist REST, und warum ist das wichtig?

Ihr API im HTTP-Verbstil

Zurück zum Initializr

Erzeugen einer einfachen Domain

GET-ting

@RestController in a Nutshell

POST-ing

PUT-ting

DELETE-ing

Und mehr

Vertrauen ist gut, Kontrolle ist besser

Zusammenfassung

4Datenbankzugriff für Ihre Spring-Boot-Anwendung

Die Autokonfiguration für den Datenbankzugriff vorbereiten

Was wollen wir erreichen?

Hinzufügen einer Datenbankabhängigkeit

Code hinzufügen

Speichern und Abrufen von Daten

Ein bisschen Nachpolieren

Zusammenfassung

5Konfigurieren und Untersuchen Ihrer Spring-Boot-Anwendung

Anwendungskonfiguration

@Value

@ConfigurationProperties

Potenzielle Drittanbieter-Option

Autoconfiguration Report

Der Actuator

Den Actuator dazu bringen, mehr zu verraten

Umweltbewusster werden mit dem Actuator

Mehr protokollieren mit dem Actuator

Zusammenfassung

6Tief in das Thema Daten einsteigen

Entitäten definieren

Template-Unterstützung

Repository-Unterstützung

@Before

Einen Template-basierten Dienst mit Redis erstellen

Das Projekt initialisieren

Den Redis-Dienst entwickeln

Von Template auf Repository umsteigen

Mit dem Java Persistence API (JPA) einen Repository-basierten Dienst erstellen

Das Projekt initialisieren

Den JPA-(MySQL-)Dienst entwickeln

Daten laden

Mithilfe einer dokumentenorientierten NoSQL-Datenbank einen Repository-basierten Dienst erstellen

Das Projekt initialisieren

Den MongoDB-Dienst entwickeln

Einen Repository-basierten Dienst mithilfe einer NoSQL-Graphdatenbank erstellen

Das Projekt initialisieren

Den Neo4j-Dienst entwickeln

Zusammenfassung

7Anwendungen mittels Spring MVC erstellen

Spring MVC: Was bedeutet das?

Endanwender-Interaktionen mittels Template-Engines

Das Projekt initialisieren

Die Aircraft-Positions-Anwendung entwickeln

Nachrichten übergeben

Den PlaneFinder ausbauen

Die Anwendung Aircraft Positions erweitern

Konversationen mit WebSocket erzeugen

Was ist WebSocket?

Die Aircraft-Positions-Anwendung umbauen

Zusammenfassung

8Reaktive Programmierung mit Project Reactor und Spring WebFlux

Einführung in die reaktive Programmierung

Project Reactor

Tomcat versus Netty

Reaktiver Datenzugriff

R2DBC mit H2

Reaktives Thymeleaf

RSocket für eine vollständig reaktive Interprozess-Kommunikation

Was ist RSocket?

RSocket einsetzen

Zusammenfassung

9Spring-Boot-Anwendungen zur erhöhten Produktionsbereitschaft testen

Unit-Tests

@SpringBootTest vorgestellt

Wichtige Unit-Tests für die Aircraft-Positions-Anwendung

Refaktorieren für ein besseres Testen

Slices testen

Zusammenfassung

10Ihre Spring-Boot-Anwendung sichern

Authentifizierung und Autorisierung

Authentifizierung

Autorisierung

Spring Security in aller Kürze

Die HTTP Firewall

Sicherheitsfilterketten

Request- und Response-Header

Implementieren einer formularbasierten Authentifizierung und Autorisierung mit Spring Security

Spring-Security-Abhängigkeiten hinzufügen

Authentifizierung hinzufügen

Autorisierung

Implementieren von OpenID Connect und OAuth2 zur Authentifizierung und Autorisierung

Die Client-Anwendung Aircraft Positions

PlaneFinder-Ressourcenserver

Zusammenfassung

11Das Deployment Ihrer Spring-Boot-Anwendung

Wieder zurück zum ausführbaren Spring-Boot-JAR

Ein »vollständig ausführbares« Spring-Boot-JAR bauen

Was bedeutet das?

JARs auspacken

Deployment von Spring-Boot-Anwendungen in Containern

Ein Container-Image aus der IDE heraus erzeugen

Ein Container-Image von der Kommandozeile aus erzeugen

Verifizieren, dass das Image existiert

Die Container-Anwendung ausführen

Hilfsmittel zum Untersuchen der Container-Images einer Spring-Boot-Anwendung

pack

dive

Zusammenfassung

12In die reaktive Programmierung intensiv eintauchen

Wann sollte man reaktiv arbeiten?

Reaktive Anwendungen testen

Zuerst aber: refaktorieren

Und nun das Testen

Diagnostizieren und Debuggen reaktiver Anwendungen

Hooks.onOperatorDebug()

Checkpoints

ReactorDebugAgent.init()

Zusammenfassung

Index

Vorwort

Willkommen

»Drachen steigen gegen den Wind auf, nicht mit ihm.«

– John Neal, aus Enterprise and Perseverance (The Weekly Mirror)

Willkommen zu Spring Boot: Cloud-native Anwendungen mit Java und Kotlin erstellen. Ich freue mich, dass Sie hier sind.

Es gibt bereits einige andere Spring-Boot-Bücher. Gute Bücher, geschrieben von guten Leuten. Doch jeder Autor bestimmt selbst, was er in sein Buch aufnimmt, was er weglässt, wie er das Material präsentiert und so weiter. Alle Entscheidungen, egal ob groß oder klein, machen das Buch einzigartig. Was ein Autor für optional hält, kann für eine andere Autorin absolut unverzichtbar sein. Wir sind alle Entwickler und haben, wie alle Entwickler, Meinungen.

Meine Meinung war, dass in anderen Büchern einige Dinge gefehlt haben, Dinge, die entweder meiner Ansicht nach notwendig sind oder die ich für hilfreich halte und mit Entwicklern teilen wollte, die neu bei Spring Boot sind. Diese Liste der fehlenden Dinge ist immer länger geworden, je mehr ich mit Entwicklern auf der ganzen Welt zu tun habe, die in verschiedenen Stadien ihrer Spring-Boot-Reise sind. Wir alle lernen unterschiedliche Dinge auf verschiedene Weise und zu unterschiedlichen Zeiten. Deshalb dieses Buch.

Falls Sie neu bei Spring Boot sind oder es für sinnvoll erachten, Ihre Kenntnisse der Grundlagen zu stärken – und ganz ehrlich, wann ist das nicht sinnvoll? –, dann seien Sie gewiss, dass dieses Buch genau für Sie gedacht ist. Es ist eine behutsame Einführung in die wichtigsten Fähigkeiten von Spring Boot, die gleichzeitig die Anwendung dieser Fähigkeiten auf Probleme in der wirklichen Welt demonstriert.

Danke, dass Sie mich auf dieser Reise begleiten. Legen wir los!

Konventionen in diesem Buch

In diesem Buch gelten die folgenden typografischen Konventionen:

Kursiv

Kennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionalschrift

Wird für Programmlistings benutzt sowie, um im Text Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen und Schlüsselwörter zu kennzeichnen.

Nichtproportionalschrift fett

Zeigt Befehle oder anderen Text, der wortwörtlich vom Anwender eingetippt werden sollte.

Nichtproportionalschrift kursiv

Zeigt Text, der durch benutzereigene Werte oder Werte, die durch den Kontext bestimmt werden, ersetzt wird.

Dieses Element kennzeichnet einen Tipp oder Vorschlag.

Dieses Element kennzeichnet eine allgemeine Anmerkung.

Dieses Element kennzeichnet eine Warnung.

Codebeispiele benutzen

Es gibt Zusatzmaterial (Codebeispiele, Übungen und so weiter) zum Herunterladen unter https://resources.oreilly.com/examples/0636920338727.

Dieses Buch soll Ihnen helfen, Ihre Aufgaben zu erledigen. Wenn Beispielcode in diesem Buch angeboten wird, dann dürfen Sie diesen in Ihren Programmen und Dokumentationen verwenden. Sie müssen uns nicht um Erlaubnis fragen, es sei denn, Sie reproduzieren einen bedeutsamen Teil des Codes. Zum Beispiel brauchen Sie keine Erlaubnis, wenn Sie ein Programm schreiben, das einige Codeausschnitte aus diesem Buch benutzt. Wenn Sie jedoch Beispiele aus O’Reilly-Büchern verkaufen oder vertreiben wollen, benötigen Sie eine Erlaubnis.

Eine Frage zu beantworten, indem Sie dieses Buch anführen und ein Beispiel zitieren, erfordert keine Erlaubnis. Wenn Sie jedoch eine beträchtliche Menge an Beispielcode aus diesem Buch in die Dokumentation Ihres Produkts aufnehmen, benötigen Sie eine Erlaubnis.

Wir wissen eine Quellenangabe zu schätzen, fordern sie aber im Allgemeinen nicht. Eine Quellenangabe enthält üblicherweise Titel, Autoren, Verlag und ISBN. Zum Beispiel: »Spring Boot: Cloud-native Anwendungen mit Java und Kotlin erstellen von Mark Heckler (O’Reilly). Copyright 2022 dpunkt.verlag GmbH, ISBN 978-3-96009-176-9«.

Falls Sie das Gefühl haben, dass Ihr Einsatz von Codebeispielen nicht durch die oben genannten Erlaubnisse abgedeckt ist, schreiben Sie uns bitte an [email protected].

Danksagungen

Ich kann denjenigen gar nicht genug danken, die mich angeregt haben, dieses Buch zu schreiben, und die mich beim Schreiben ermutigt haben. Sie wissen gar nicht, wie viel es mir bedeutete, falls Sie Vorabveröffentlichungen gelesen und über Twitter Feedback gegeben oder vielleicht auch nur Worte des Zuspruchs geäußert haben. Ihnen gebührt mein tiefster Dank.

Es gibt einige Menschen, die das Ganze ermöglicht haben, sodass es nicht nur ein hoffnungsvoller Plan geblieben ist, irgendwann einmal ein Buch zu schreiben:

An meine Chefin, Mentorin und Freundin Tasha Isenberg. Tasha, du hast mir geholfen, Zeitpläne einzuhalten, und hast mir auch einmal den Weg freigeräumt, damit ich wichtige Deadlines schaffen konnte. Ich bin wirklich dankbar, dass ich eine solch verständnisvolle und energische Unterstützerin bei VMware habe.

An Dr. David Syer, Gründer von Spring Boot, Spring Cloud, Spring Batch und Mitwirkender an zahllosen Spring-Projekten. Ihre Einsichten und Ihr Feedback waren wirklich außergewöhnlich und unglaublich durchdacht, und ich kann Ihnen gar nicht genug für alles danken.

An Greg Turnquist, Teammitglied von Spring Data. Danke für deinen kritischen Blick und das schonungslose Feedback; du hast eine wertvolle zusätzliche Perspektive geboten und das Buch dadurch entschieden verbessert.

An meine Lektorinnen Corbin Collins und Suzanne (Zan) McQuade. Ihr habt mir von der Konzeption bis zur Fertigstellung außerordentlich hilfreich zur Seite gestanden, mich ermutigt, mein Bestes zu geben, und es mir ermöglicht, irgendwie Deadlines einzuhalten, die durch äußere Umstände bedroht schienen. Ich hätte mir nichts Besseres wünschen können.

An Rob Romano, Caitlin Ghegan, Kim Sandoval und das gesamte O’Reilly-Produktionsteam. Ihr habt mich über die Ziellinie gehievt, indem ihr mir auf den wichtigen letzten Metern geholfen habt.

Schließlich, und das ist am wichtigsten, an meine geniale, liebevolle und überaus geduldige Frau Kathy. Zu sagen, dass du mich inspirierst und es mir ermöglichst, all das zu machen, ist die größte aller Untertreibungen. Ich danke dir aus allertiefstem Herzen für alles.

KAPITEL 1

Spring Boot in a Nutshell

Dieses Kapitel erkundet die drei Kerneigenschaften von Spring Boot und untersucht, wie diese Ihnen als Entwickler zur Seite stehen.

Die drei Grundeigenschaften von Spring Boot

Die drei Kerneigenschaften von Spring Boot, auf denen alles andere aufbaut, sind ein vereinfachtes Abhängigkeitsmanagement, ein vereinfachtes Deployment und die Autokonfiguration.

Starter für vereinfachtes Abhängigkeitsmanagement

Einer der genialen Aspekte von Spring Boot besteht darin, dass es das Dependency- oder Abhängigkeitsmanagement handhabbar macht.

Falls Sie bereits einmal ernsthaft Software entwickelt haben, mussten Sie sich bestimmt schon mehrfach den Kopf hinsichtlich des Abhängigkeitsmanagements zerbrechen. Jede Fähigkeit, die Sie mit Ihrer Anwendung anbieten, erfordert im Vorfeld üblicherweise eine Reihe von Abhängigkeiten. Falls Sie zum Beispiel ein RESTful-Web-API bereitstellen, müssen Sie eine Möglichkeit zur Verfügung stellen, Endpoints über HTTP anzubieten, auf Anfragen (Requests) zu lauschen, diese Endpoints an Methoden/Funktionen zu binden, die diese Anfragen verarbeiten, um dann passende Antworten (Responses) zu erzeugen und zurückzuliefern.

Jede primäre Abhängigkeit zieht fast zwangsläufig zahllose weitere sekundäre Abhängigkeiten nach sich, um ihre versprochene Funktionalität zu erfüllen. Um bei unserem Beispiel eines RESTful-API zu bleiben: Wir können eine Reihe von Abhängigkeiten erwarten (in einer vernünftigen, wenn auch strittigen Struktur), die Code enthalten, der Responses in einem bestimmten Format liefert, z.B. JSON, XML, HTML, Code zum Marshalling/Demarshalling von Objekten in bestimmte Formate, Code zum Lauschen auf und Verarbeiten von Anfragen und zum Zurückgeben von Antworten auf diese, Code zum Decodieren komplexer URIs, die benutzt werden, um vielseitige APIs zu erzeugen, Code zum Unterstützen verschiedener Übertragungsprotokolle und mehr.

Selbst für dieses relativ einfache Beispiel müssen wir wahrscheinlich schon mit einer großen Anzahl von Abhängigkeiten in unserer Build-Datei rechnen. Und wir haben an dieser Stelle noch gar nicht darüber nachgedacht, welche Art Funktionalität wir in unsere Anwendung aufnehmen wollen, sondern nur ihre nach außen gerichteten Interaktionen betrachtet.

Reden wir nun über Versionen und über jeder einzelne dieser Abhängigkeiten.

Die gemeinsame Benutzung von Bibliotheken erfordert eine gewisse Präzision, da es sein kann, dass eine Version einer speziellen Abhängigkeit nur mit einer bestimmten Version einer anderen Abhängigkeit getestet wurde (oder gar nur mit ihr korrekt funktioniert). Solche Probleme, die unweigerlich auftauchen, bezeichne ich als »Abhängigkeits-Whack-a-Mole« (»Hau den Maulwurf«).

Genau wie das namengebende Spiel kann auch Abhängigkeits-Whack-a-Mole sehr frustrierend sein. Anders als bei dem Spiel gibt es jedoch keine Preise zu gewinnen, wenn man Bugs, die aus falschen Zuordnungen resultieren, jagt und zerhaut, sondern höchstens seltsame Diagnosen und Stunden, die man mit der Suche nach ihnen verplempert hat.

Doch jetzt kommen Spring Boot und seine Starter. Spring-Boot-Starter sind Bills of Materials (BOMs; also quasi Stücklisten), die aufgrund der erwiesenen Tatsache erstellt werden, dass Sie eine bestimmte Funktion in der Mehrzahl der Fälle auf nahezu dieselbe Weise bereitstellen.

Jedes Mal, wenn wir im oben angeführten Beispiel ein API bauen, stellen wir Endpoints bereit, lauschen auf Anfragen, verarbeiten die Anfragen, wandeln Objekte um, tauschen Informationen in verschiedenen Standardformaten aus, senden und empfangen Daten mit einem bestimmten Protokoll über die Leitung und mehr. Dieses Muster aus Entwurf/Entwicklung/Benutzung ändert sich nicht sehr, sondern ist ein branchenübliches Vorgehen, das so oder so ähnlich verwendet wird. Und wie andere vergleichbare Muster lässt es sich sehr schön in einem Spring-Boot-Starter festhalten.

Das Hinzufügen eines einzigen Starters, z.B. spring-boot-starter-web, fasst alle dazugehörigen Funktionalitäten in einer einzigen Anwendungsabhängigkeit zusammen. Alle Abhängigkeiten, die in diesem einen Starter enthalten sind, sind darüber hinaus versionssynchronisiert. Das heißt, sie wurden erfolgreich zusammen getestet, und die enthaltene Version von Bibliothek A funktioniert einwandfrei mit der enthaltenen Version von Bibliothek B … und C … und D und so weiter. Dadurch wird unsere Liste mit den Abhängigkeiten und damit unser Leben drastisch vereinfacht, da es ziemlich unwahrscheinlich wird, dass schwer zu identifizierende Versionskonflikte zwischen Abhängigkeiten auftreten, die Sie für die wichtigen Funktionen Ihrer Anwendung zur Verfügung stellen müssen.

In den seltenen Fällen, in denen Sie Funktionalität einbauen müssen, die von einer anderen Version einer enthaltenen Abhängigkeit bereitgestellt wird, können Sie die getestete Version einfach übergehen.

Falls Sie sich über die vorgegebene Version einer Abhängigkeit hinwegsetzen müssen, dann tun Sie das … allerdings sollten Sie dann wahrscheinlich Ihre Tests ausweiten, um die Risiken auszuschalten, die Sie sich durch Ihr Vorgehen möglicherweise einhandeln.

Sie können Abhängigkeiten, die für Ihre Anwendung unnötig sind, auch ausschließen. Dabei gelten allerdings dieselben Vorsichtsmaßnahmen.

Alles in allem rationalisiert das Starter-Konzept von Spring Boot Ihre Abhängigkeiten und verringert den Aufwand, der nötig ist, um ganze Gruppen von Fertigkeiten in Ihre Anwendungen einzubauen. Es verringert außerdem den für Tests, Wartung und Aktualisierung anfallenden Overhead.

Ausführbare JARs für ein vereinfachtes Deployment

Vor langer, langer Zeit, als Application-Server über die Erde streiften, waren Deployments von Java-Anwendungen eine komplexe Angelegenheit.

Um eine funktionierende Anwendung mit z.B. Datenbankzugriff auf den Weg zu bringen – wie bei vielen Microservices heutzutage und fast allen Monolithen damals und heute –, müssten Sie Folgendes tun:

Installieren und Konfigurieren des Application-Servers

Installieren der Datenbanktreiber

Erzeugen einer Datenbankverbindung

Erzeugen eines Connection Pools

Kompilieren und Testen Ihrer Anwendung

Deployment Ihrer Anwendung und deren (meist zahlreichen) Abhängigkeiten auf dem Application-Server

Diese Liste geht übrigens davon aus, dass Administratoren die Maschine/virtuelle Maschine für Sie konfigurieren und Sie irgendwann einmal unabhängig von diesem Prozess die Datenbank erzeugt haben.

Spring Boot stellte einen Großteil dieses schwerfälligen Deployment-Prozesses auf den Kopf und fasste die genannten Schritte zu einem einzigen Schritt zusammen – vielleicht auch zwei, falls Sie das Kopieren oder Verschieben einer einzelnen Datei (mit cf push) als tatsächlichen Schritt betrachten wollen.

Spring Boot war nicht der Ursprung des sogenannten Über-JAR, hat es aber revolutioniert. Anstatt jede Datei aus dem Anwendungs-JAR und allen abhängigen JARs herauszukitzeln, sie dann zu einem einzigen Ziel-JAR zu kombinieren – ein Vorgang, der manchmal als Shading bezeichnet wird –, gingen die Entwickler von Spring Boot die Sache von einer ganz neuen Seite an: Was wäre, wenn wir JARs schachteln und dabei ihr vorgesehenes und übergebenes Format beibehalten könnten?

Das Schachteln von JARs anstelle des Shading behebt viele potenzielle Probleme, da uns keine etwaigen Versionskonflikte begegnen werden, wenn Abhängigkeit JAR A und Abhängigkeit JAR B jeweils eine andere Version von C benutzen; es lässt auch potenzielle rechtliche Probleme verschwinden, die auftreten, wenn man Software neu packt und sie mit anderer Software kombiniert, die eine andere Lizenz verwendet. Behält man alle abhängigen JARs in ihrem Ursprungsformat, dann vermeidet man ganz geschickt diese und andere Probleme.

Es ist außerdem trivial, den Inhalt eines ausführbaren JAR in Spring Boot zu extrahieren, sollten Sie dies wünschen. Unter bestimmten Umständen gibt es gute Gründe dafür, und ich werde darauf in diesem Buch eingehen. Für den Augenblick reicht es, zu wissen, dass das ausführbare JAR in Spring Boot für Sie da ist.

Das einzelne Spring-Boot-JAR mit all den Abhängigkeiten macht das Deployment zu einem Kinderspiel. Anstatt alle Abhängigkeiten zu sammeln und sicherzustellen, dass sie deployt werden, sorgt das Spring-Boot-Plug-in dafür, dass sie in das Ausgabe-JAR eingebunden werden. Ist das erledigt, kann die Anwendung überall ausgeführt werden, wo es eine Java Virtual Machine (JVM) gibt. Es reicht, dazu einen Befehl wie java -jar <SpringBootAppName.jar> auszuführen.

Da gibt es aber noch mehr.

Durch Einstellen einer einzigen Eigenschaft in Ihrer Build-Datei kann das Spring-Boot-Build-Plug-in dieses eine JAR vollständig (selbst) ausführbar machen. Immer noch unter der Voraussetzung, dass es eine JVM gibt, müssen Sie nun nicht die ganze lästige Zeile java -jar <SpringBootAppName.jar eintippen, sondern können die Ausführung mit einem einfachen <SpringBootAppName.jar> erreichen (natürlich müssen Sie hier Ihren eigenen Dateinamen einsetzen) – das war es auch schon. Einfacher geht es wirklich nicht.

Autokonfiguration

Die Autokonfiguration, die Spring-Boot-Neulingen manchmal wie Zauberei erscheinen mag, ist vielleicht der größte »Machtmultiplikator«, den Entwickler durch Spring Boot gewinnen. Ich bezeichne sie oft als die Superkraft eines Entwicklers: Spring Boot gibt Ihnen wahnsinnige Produktivität, indem es Meinungen zu weit verbreiteten und oft wiederholten Use Cases äußert.

Meinungen in Software? Und das hilft?!?

Wenn Sie schon lange als Entwickler unterwegs sind, dann haben Sie zweifellos bemerkt, dass sich manche Muster oft wiederholen. Natürlich nicht perfekt, aber zu einem großen Teil; vielleicht 80 bis 90 Prozent der Zeit bewegen sich die Dinge in einem bestimmten Bereich aus Design, Entwicklung oder Aktivität.

Ich habe bereits auf diese Wiederholung in der Software hingedeutet, da sie es ist, die Spring-Boot-Starter so unglaublich konsistent und nützlich macht. Wiederholung bedeutet auch, dass sich diese Aktivitäten, wenn wir dann zu dem Code kommen, der zum Erledigen einer bestimmten Aufgabe geschrieben werden muss, hervorragend für eine Rationalisierung anbieten.

Um einmal ein Beispiel aus Spring Data zu borgen, ein mit Spring Boot verwandtes und durch Spring Boot ermöglichtes Projekt: Wir wissen, dass wir jedes Mal, wenn wir Zugriff auf eine Datenbank benötigen, irgendeine Art von Verbindung zu dieser Datenbank öffnen müssen. Wir wissen außerdem, dass diese Verbindung geschlossen werden muss, wenn unsere Anwendung ihre Aufgaben erledigt hat, um potenzielle Probleme zu vermeiden. Zwischen dem Öffnen und Schließen richten wir wahrscheinlich zahlreiche Anforderungen an die Datenbank, für die wir Abfragen benutzen – einfache und komplexe, schreibgeschützte und schreibbare. Die korrekte Erstellung dieser Abfragen erfordert eine gewisse Mühe.

Stellen Sie sich nun vor, wir könnten all das rationalisieren. Automatisch eine Verbindung öffnen, wenn wir die Datenbank angeben. Automatisch die Verbindung schließen, wenn die Anwendung fertig ist. Einfachen und erwarteten Konventionen folgen, um mit minimalem Aufwand Ihrerseits automatisch Abfragen zu erzeugen. Wieder durch eine einfache Konvention eine einfache Anpassung selbst dieses minimalen Codes erlauben, um komplexe, spezialisierte Abfragen zu erzeugen, die zuverlässig konsistent und effizient sind.

Diese Herangehensweise an Code wird manchmal als Konvention vor Konfiguration bezeichnet und kann auf den ersten Blick irritierend wirken, wenn eine bestimmte Konvention Ihnen neu ist. Falls Sie jedoch vorher schon einmal Ähnliches implementiert haben und viele Hundert Zeilen lang den immer wieder gleichen Setup/Teardown/Konfigurationscode schreiben mussten, um selbst die einfachen Aufgaben zu erledigen, dürfte dies sehr erfrischend sein. Spring Boot (und die meisten Spring-Projekte) folgen dem Mantra Konvention vor Konfiguration und bieten Ihnen damit die Versicherung, dass Sie nur ein Minimum an Konfigurationscode (oder überhaupt keinen) schreiben müssen, wenn Sie sich an einfache, wohletablierte und -dokumentierte Konventionen halten.

Ein anderer Aspekt, über den die Autokonfiguration Ihnen Superkräfte verleiht, ist die Tatsache, dass für das Spring-Team die Entwickler an erster Stelle stehen, vor allem auch, wenn es um die Konfiguration der Umgebung geht. Als Entwickler sind wir am produktivsten, wenn wir uns auf die zu lösende Aufgabe konzentrieren können und uns nicht mit einer Unmenge von Setup-Kleinigkeiten befassen müssen. Wie schafft Spring Boot das?

Borgen wir uns ein Beispiel aus einem anderen Spring-Boot-verwandten Projekt, Spring Cloud Stream: Wenn eine Verbindung zu einer Messaging-Plattform wie RabbitMQ oder Apache Kafka hergestellt werden soll, muss ein Entwickler typischerweise zuerst bestimmte Einstellungen für die genannte Plattform festlegen, um sich mit ihr verbinden und sie nutzen zu können – Hostname, Port, Zugangsdaten und mehr. Die Konzentration auf das eigentliche Entwickeln bedeutet, dass Standardwerte angegeben werden, die das lokale Arbeiten des Entwicklers unterstützen, falls keine festgelegt wurden: Localhost, Standardport und so weiter. Das ist quasi eine Meinung, weil es für Entwicklungsumgebungen fast zu 100 Prozent konsistent ist, wenn es auch in Produktionsumgebungen nicht der Fall ist. In diesen müssten Sie aufgrund der vielen unterschiedlichen Plattformen und Hosting-Umgebungen spezielle Werte angeben.

Nutzt man diese Standardwerte in geteilten Entwicklungsprojekten, spart man ebenfalls viel Zeit beim Setup für die Entwicklungsumgebung. Das ist ein Vorteil für Sie und für Ihr Team.

Es gibt natürlich Gelegenheiten, bei denen Ihre speziellen Anwendungsfälle nicht exakt zu den 80 bis 90 Prozent der typischen Anwendungsfälle passen. Sollte Ihr Fall in die Kategorie der restlichen 10 bis 20 Prozent Anwendungsfälle gehören, kann die Autokonfiguration selektiv außer Kraft gesetzt oder ganz deaktiviert werden. Sie verlieren dann aber natürlich Ihre Superkräfte. Das Übergehen bestimmter Meinungen ist üblicherweise eine Angelegenheit, bei der eine oder mehrere Eigenschaften gesetzt werden, um etwas zu erreichen, was Spring Boot normalerweise automatisch für Sie konfigurieren würde. Meist ist das relativ einfach, selbst wenn es selten vorkommt. Die Autokonfiguration ist ein machtvolles Werkzeug, das stillschweigend und pausenlos in Ihrem Sinne tätig ist, um Ihnen das Leben zu erleichtern und Sie unglaublich produktiv zu machen.

Zusammenfassung

Die drei Kerneigenschaften von Spring Boot, auf denen alles andere aufbaut, sind vereinfachtes Abhängigkeitsmanagement, vereinfachtes Deployment und Autokonfiguration. Alle drei lassen sich an Ihre Anforderungen anpassen, auch wenn das selten nötig ist. Und alle drei dienen vor allem dazu, Sie zu einem besseren und produktiveren Entwickler zu machen. Spring Boot verleiht Ihnen Flügel!

Im nächsten Kapitel schauen wir uns die großartigen Möglichkeiten an, die Ihnen zur Verfügung stehen, wenn Sie beginnen, Spring-Boot-Anwendungen herzustellen. Sie haben die Wahl, und das ist gut so!

KAPITEL 2

Ihre Werkzeuge auswählen und beginnen

Wie Sie bald sehen werden, ist es einfach, mit dem Erstellen von Spring-Boot-Anwendungen anzufangen. Der schwierigste Teil dürfte sein, zu entscheiden, welche der verfügbaren Möglichkeiten Sie wählen sollten.

In diesem Kapitel schauen wir uns einige der ausgezeichneten Möglichkeiten an, die für Sie verfügbar sind, um Spring-Boot-Anwendungen herzustellen: Build-Systeme, Sprachen, Toolchains, Codeeditoren und so weiter.

Maven oder Gradle?

Java-Anwendungsentwicklern standen immer schon mehrere Build-Werkzeuge für ihre Projekte zur Verfügung. Einige von ihnen sind mit der Zeit – aus gutem Grund – aus der Mode geraten, sodass heute vor allem zwei Werkzeuge verwendet werden: Maven und Gradle. Spring Boot unterstützt beide gleichermaßen.

Apache Maven

Maven ist eine beliebte und solide Wahl für ein Build-Automatisierungssystem. Es existiert schon eine ganze Weile: Nachdem es 2002 erschienen ist, wurde es 2003 zu einem der wichtigen Projekte der Apache Software Foundation erklärt. Sein deklarativer Ansatz war zu damaliger Zeit und ist auch heute noch konzeptuell einfacher als die Alternativen: Sie erzeugen einfach eine XML-formatierte Datei namens pom.xml mit den gewünschten Abhängigkeiten und Plug-ins. Wenn Sie den Befehl mvn ausführen, können Sie eine »Phase« angeben, die fertiggestellt werden soll. Dadurch wird eine gewünschte Aufgabe ausgeführt, wie das Kompilieren, Entfernen früherer Ausgaben, Verpacken, Ausführen einer Anwendung und so weiter:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

https://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<parent>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-parent</artifactId>

<version>2.4.0</version>

<relativePath/> <!-- lookup parent from repository -->

</parent>

<groupId>com.example</groupId>

<artifactId>demo</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>demo</name>

<description>Demo project for Spring Boot</description>

<properties>

<java.version>11</java.version>

</properties>

<dependencies>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-test</artifactId>

<scope>test</scope>

</dependency>

</dependencies>

<build>

<plugins>

<plugin>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

</plugin>

</plugins>

</build>

</project>

Maven erzeugt und erwartet per Konvention außerdem eine spezielle Projektstruktur. Es ist nicht ratsam, von dieser Struktur abzuweichen, wenn Sie nicht gerade planen, sich mit Ihrem Build-Werkzeug herumzustreiten, was eine wirklich schlechte Idee wäre. Für die große Mehrheit der Projekte funktioniert die konventionelle Maven-Struktur ganz hervorragend, sodass Sie hier kaum etwas ändern müssen. Abbildung 2-1 zeigt eine Spring-Boot-Anwendung mit der typischen Maven-Projektstruktur.

Abbildung 2-1: Maven-Projektstruktur in einer Spring-Boot-Anwendung

Näheres über die Projektstruktur, die Maven erwartet, erfahren Sie in The Maven Project’s Introduction to the Standard Directory Layout (https://oreil.ly/mavenprojintro).

Falls einmal der Zeitpunkt kommt, an dem die Projektkonventionen von Maven und/oder das eng strukturierte Vorgehen für Builds Sie zu sehr einschränken, haben Sie eine andere ausgezeichnete Möglichkeit.

Gradle

Gradle ist eine andere beliebte Möglichkeit für das Erstellen von Java-Virtual-Machine-(JVM-)Projekten. Veröffentlicht im Jahre 2008, nutzt Gradle eine domänenspezifische Sprache (Domain Specific Language; DSL), um die Build-Datei build. gradle anzulegen, die sowohl minimal als auch flexibel ist. Hier sehen Sie ein Beispiel einer Gradle-Build-Datei für eine Spring-Boot-Anwendung.

Gradle erlaubt Ihnen als Entwickler, als DSL die Programmiersprachen Groovy oder Kotlin zu verwenden. Außerdem besitzt es verschiedene Eigenschaften, die dazu dienen, die Wartezeit beim Building eines Projekts zu verringern:

inkrementelles Kompilieren von Java-Klassen

Vermeiden des Kompilierens für Java (in Fällen, in denen keine Änderungen aufgetreten sind)

einen dedizierten Dämon für die Projektkompilierung

Die Wahl zwischen Maven und Gradle

Augenscheinlich überwiegen die Vorteile von Gradle … warum also nicht einfach dieses Build-Werkzeug nutzen?

Mavens strengerer deklarativer (manche sagen sogar starrsinniger) Ansatz sorgt jedoch dafür, dass die Dinge von Projekt zu Projekt und von Umgebung zu Umgebung unglaublich konsistent bleiben. Wenn Sie den Maven-Weg gehen, treten üblicherweise kaum Probleme auf. Sie können sich also auf Ihren Code konzentrieren, ohne sich große Gedanken um den Build machen zu müssen.

Als Build-System, das auf Programmierung/Skripting setzt, hat Gradle gelegentlich auch Probleme mit ersten Fassungen von neuen Sprachversionen. Das Gradle-Team reagiert normalerweise sehr schnell und räumt diese Probleme aus, doch falls Sie sofort auf frühe Sprachversionen wechseln wollen oder müssen, sollten Sie dies beachten.

Gradle kann für Builds schneller sein – manchmal sogar signifikant schneller, vor allem in größeren Projekten. Bei Ihren typischen microservicebasierten Projekten werden sich die Build-Zeiten zwischen vergleichbaren Maven- und Gradle-Projekten jedoch wahrscheinlich kaum unterscheiden.

Die Flexibilität von Gradle kann bei einfachen Projekten und bei Projekten mit sehr komplexen Build-Anforderungen sehr erfrischend sein. Allerdings kann sie vor allem in diesen komplexen Projekten auch bedeuten, dass Sie mehr Zeit zum Anpassen und zur Fehlersuche benötigen, falls etwas nicht so funktioniert, wie Sie es erwarten. Alles hat seinen Preis. TANSTAAFL (There Ain’t No Such Thing as a Free Lunch).

Spring Boot unterstützt sowohl Maven als auch Gradle. Wenn Sie den Initializr benutzen (auf den wir in einem folgenden Abschnitt eingehen werden), werden das Projekt und die gewünschte Build-Datei für Sie angelegt, sodass Sie schnell loslegen können. Spring Boot hilft Ihnen in jedem Fall gerne.

Java oder Kotlin?

Es gibt zwar viele Sprachen, die man in der JVM benutzen könnte, doch zwei sind ganz besonders weit verbreitet. Eines ist die ursprüngliche JVM-Sprache: Java; die andere ist relativ neu in dem Bereich: Kotlin. Beide sind in Spring Boot voll einsatzfähig.

Java

Je nachdem, ob Sie die Freigabe der Version 1.0 oder den Anfang des Projekts als offizielles Geburtsdatum ansetzen, gibt es Java jetzt schon seit 25 beziehungsweise 30 Jahren. Dennoch ist Java nicht stehen geblieben, ganz im Gegenteil. Seit September 2017 befindet sich Java in einem sechsmonatigen Releasezyklus, der viel häufigere Verbesserungen seiner Funktionen zur Folge hat als bisher. Die Entwickler haben die Codebasis aufgeräumt und Elemente entfernt, die von Neuzugängen »überholt« worden sind. Außerdem haben sie wichtige Funktionen eingeführt, die von der Java-Gemeinschaft gewünscht waren. Java ist lebendiger als je zuvor.

Dieses hohe Innovationstempo bedeutet in Kombination mit der Langlebigkeit von Java und dem steten Fokus auf der Abwärtskompatibilität, dass es weltweit zahlreiche Java-Programmierer gibt, die wichtige Java-Anwendungen entwickeln und pflegen. Viele dieser Anwendungen benutzen Spring.

Java bildet das grundsolide Fundament nahezu der gesamten Spring-Codebasis und ist entsprechend eine großartige Wahl zum Bauen Ihrer Spring-Boot-Anwendungen. Um den Code für Spring, Spring Boot und alle verwandten Projekte zu untersuchen, müssen Sie einfach nur die GitHub-Website besuchen, wo dieser vorgehalten wird, und ihn dort anschauen oder für eine Offline-Begutachtung klonen. Und da eine Vielzahl von Beispielcode, Beispielprojekten und »Getting Started«-Anleitungen auf der Grundlage von Java verfügbar ist, werden Spring-Boot-Anwendungen auf Java-Grundlage vermutlich besser unterstützt als jede andere Tool-chain-Kombination auf dem Markt.

Kotlin

Im Vergleich dazu ist Kotlin noch ein ziemlicher Frischling. Erschaffen von Jet-Brains im Jahre 2010 und der Öffentlichkeit vorgestellt im Jahre 2011, soll Kotlin vermeintliche Lücken in der Brauchbarkeit von Java schließen. Kotlin wurde so entworfen, dass es sich durch folgende Attribute auszeichnet:

Knapp und präzise

Kotlin erfordert nur minimalen Code, um dem Compiler (sowie den Entwicklern) ganz deutlich seine Absichten zu kommunizieren.

Sicher

Kotlin eliminiert nullbezogene Fehler, indem es standardmäßig die Möglichkeit von Nullwerten ausschließt, es sei denn, der Entwickler erlaubt dieses Verhalten explizit.

Vollständig kompatibel

Kotlin zielt auf eine reibungslose Interoperabilität mit allen existierenden JVM-, Android- und Browser-Bibliotheken ab.

Werkzeugfreundlich

Kotlin-Anwendungen können genau wie Java in zahlreichen Integrated Development Environments (IDEs) oder von der Kommandozeile aus gebaut werden.

Die Kotlin-Entwickler erweitern die Fähigkeiten der Sprache sehr sorgfältig, aber auch schnell. Da sie bei der Weiterentwicklung der Sprache keine 25 Jahre an Sprachkompatibilität berücksichtigen müssen, können sie schon jetzt nützliche Fähigkeiten hinzufügen, die in Java vermutlich erst in einigen Versionen auftauchen werden.

Kotlin ist nicht nur eine knappe und präzise, sondern auch eine sehr flüssige Sprache. Ohne bereits zu sehr ins Detail gehen zu wollen, lässt sich dennoch sagen, dass verschiedene Spracheigenschaften zu dieser linguistischen Eleganz beitragen, darunter die Erweiterungsfunktionen und die Infix-Notation. Ich werde später noch näher darauf eingehen, doch Kotlin erlaubt solche Syntaxmöglichkeiten:

infix fun Int.multiplyBy(x: Int): Int { ... }

// Der Aufruf der Funktion mithilfe der Infix-Notation

1 multiplyBy 2

// ist das Gleiche wie

1.multiplyBy(2)

Wie Sie sich vorstellen können, kann die Fähigkeit, Ihre eigene, flüssigere »Sprache in einer Sprache« zu definieren, ein Segen beim API-Entwurf sein. Zusammen mit der Knappheit von Kotlin kann dies Spring-Boot-Anwendungen, die in Kotlin geschrieben wurden, noch kürzer und lesbarer machen als ihre Java-Gegenstücke, ohne dass die Kommunikation der Absichten beeinträchtigt wird.

Kotlin ist seit der Veröffentlichung von Version 5.0 im Herbst 2017 ein vollwertiges Mitglied des Spring-Frameworks und wird seither durch Spring Boot (Frühling 2018) und andere Projekte voll unterstützt. Darüber hinaus sind alle Spring-Dokumentationen so erweitert worden, dass sie Beispiele sowohl in Java als auch in Kotlin enthalten. Das bedeutet, dass Sie ganze Spring-Boot-Anwendungen genauso einfach mit Kotlin schreiben können wie mit Java.

Zwischen Java und Kotlin wählen

Genial ist, dass Sie eigentlich gar nicht wählen müssen. Beim Kompilieren mit Kotlin erhalten Sie die gleiche Bytecode-Ausgabe wie mit Java; und da Spring-Projekte erstellt werden können, die sowohl Java- als auch Kotlin-Quelldateien enthalten und beide Compiler gleichermaßen leicht aufrufen können, können Sie sogar innerhalb desselben Projekts das benutzen, was Ihnen am sinnvollsten erscheint. Sozusagen das Beste aus beiden Welten.

Falls Sie natürlich das eine oder andere bevorzugen oder andere persönliche oder professionelle Vorgaben beachten müssen, steht es Ihnen selbstverständlich frei, die ganze Anwendung in der einen oder der anderen Sprache zu entwickeln. Es ist gut, wenn man die Wahl hat, oder?!

Eine Version von Spring Boot wählen

Für Produktionssysteme sollten Sie immer die aktuelle Version von Spring Boot benutzen, mit folgenden temporären und wenigen Ausnahmen:

Sie betreiben momentan eine ältere Version, sind aber gerade dabei, Ihre Anwendungen zu aktualisieren, zu testen und neu herauszubringen, und sind einfach noch nicht bis zu dieser speziellen Anwendung gekommen.

Sie betreiben momentan eine ältere Version, aber es gibt einen bekannten Konflikt oder Bug, den Sie dem Spring-Team gemeldet haben, und nun sind Sie darauf angewiesen, auf ein Update für Boot oder eine bestimmte Abhängigkeit zu warten.

Sie müssen Funktionen in einer Snapshot-, Milestone- oder Release-Kandidaten-Version pre-GA (General Availability; Allgemeine Verfügbarkeit) nutzen und sind bereit, die Risiken zu akzeptieren, die mit Code einhergehen, der noch nicht als GA, das heißt »bereit für den Produktionseinsatz«, erklärt wurde.

Snapshot-, Milestone- und Release-Candidate-(RC-)Versionen werden vor ihrer Veröffentlichung umfassend getestet, sodass schon viel Mühe aufgewendet wurde, um ihre Stabilität sicherzustellen. Bis die GA-Version dann jedoch vollständig gebilligt und veröffentlicht wird, kann es immer noch zu Änderungen an dem API, zu Fehlerbehebungen und so weiter kommen. Die Risiken für Ihre Anwendung sind überschaubar, aber Sie müssen für sich selbst entscheiden (und testen und bestätigen), ob die Risiken den Einsatz von Vorversionen von Software wert sind.

Der Spring Initializr

Es gibt viele Möglichkeiten, eine Spring-Boot-Anwendung herzustellen. Die meisten greifen auf einen einzelnen Ausgangspunkt zurück: den Spring Initializr, den Sie in Abbildung 2-2 sehen.

Abbildung 2-2: Der Spring Initializr

Der Spring Initializr, der manchmal einfach nur durch seine URL, start.spring.io, bezeichnet wird, kann von Projekterzeugungs-Wizards in bekannten IDEs über die Kommandozeile oder auch über einen Webbrowser erreicht werden. Wenn Sie den Webbrowser verwenden, stehen Ihnen einige zusätzliche nützliche Funktionen zur Verfügung, die Sie über die anderen Möglichkeiten (noch) nicht haben.

Um ein Spring-Boot-Projekt auf dem »bestmöglichen Weg« anzulegen, rufen Sie Ihren Browser auf und gehen auf die Seite https://start.spring.io. Dort stellen wir einige Optionen ein, und schon geht es los.

Java installieren

Wenn Sie bis zu dieser Stelle gekommen sind, haben Sie vermutlich bereits eine aktuelle Version des Java Development Kit (JDK) – manchmal als Java Platform, Standard Edition – auf Ihrem Rechner installiert. Falls nicht, müssen Sie das nachholen, bevor Sie weitermachen.

Ausführliche Anweisungen zur Installation würden den Rahmen dieses Buchs sprengen, doch einige Empfehlungen sollten nicht schaden:

Ich habe festgestellt, dass es am einfachsten ist, ein oder mehrere JDKs auf der Maschine zu installieren und zu verwalten, wenn man SDKMAN! (https://sdkman.io/) verwendet. Dieser Paketmanager hilft unter anderem auch bei der Installation des Spring Boot Command Line Interface (CLI), das Sie später benutzen werden; er ist also eine durchaus sehr sinnvolle Anwendung. Folgen Sie einfach den Anweisungen unter https://sdkman.io/install.

SDKMAN! ist in bash-Skript (der Unix-/Linux-Shell) geschrieben und kann entsprechend nativ auf macOS und Linux sowie auf anderen Betriebssystemen auf Unix- oder Linux-Basis installiert und betrieben werden. SDKMAN! läuft auch unter Windows, allerdings nicht nativ; um SDKMAN! in einer Windows-Umgebung zu installieren und auszuführen, müssen Sie zuerst das Windows Subsystem for Linux (WSL) (https://oreil.ly/WindowsSubL), Git Bash for Windows (https://oreil.ly/GitBashWin) sowie MinGW (http://www.mingw.org/) installieren. Näheres erfahren Sie auf der oben angegebenen SDKMAN!-Installationsseite.

Von SDKMAN! aus installieren Sie die gewünschte Java-Version mittels sdk list java, um die Optionen anzuschauen, dann sdk install java <hier_gewünschtes_ java_einfügen> zum Installieren. Es gibt eine ganze Menge toller Optionen. Für den Anfang empfehle ich, dass Sie die aktuelle Long-Term-Support-(LTS-)Version wählen, verpackt durch AdoptOpenJDK mit der Hotspot-JVM, z.B. 11.0.7.hs-adpt.

Sollten Sie aus irgendeinem Grund nicht SDKMAN! benutzen wollen, können Sie auch einfach ein JDK direkt von https://adoptopenjdk.net herunterladen und installieren. Damit lässt sich auch loslegen, allerdings ist es schwieriger, Updates durchzuführen oder mehrere JDKs zu verwalten.

Um mit dem Initializr anzufangen, wählen wir zuerst das Build-System, das wir mit unserem Projekt benutzen möchten. Wie bereits erwähnt, haben wir zwei großartige Möglichkeiten: Maven und Gradle. Nehmen wir für dieses Beispiel Maven.

Als Nächstes wählen wir Java als (Sprach-)Basis für dieses Projekt.

Wie Sie bemerken, legt der Spring Initializr für die präsentierten Optionen genügend Vorgaben fest, um ein Projekt anzulegen, ohne dass Sie selbst irgendetwas eingeben müssten. Wenn Sie die Webseite https://start.spring.io erreicht haben, waren Maven und Java schon vorausgewählt. Auch die aktuelle Version von Spring Boot ist eingestellt, und das ist für dieses Projekt – und die meisten Projekte – völlig in Ordnung.

Wir können die Optionen unter Project Metadata momentan so lassen, werden sie aber in künftigen Projekten ändern.

Und momentan fügen wir auch noch keine Abhängigkeiten hinzu. Auf diese Weise können wir uns auf die Mechanik der Projekterstellung konzentrieren und müssen uns nicht mit einem bestimmten Ergebnis befassen.

Bevor wir jedoch dieses Projekt generieren, möchte ich auf einige wirklich nette Eigenschaften des Spring Initializr hinweisen und noch eine Anmerkung machen.

Falls Sie vor der Projektgenerierung anhand der aktuellen Einstellungen die Metadaten und die Details der Abhängigkeiten Ihres Projekts untersuchen wollen, klicken Sie auf den Button Explore oder betätigen das Tastenkürzel Ctrl+Space. Dadurch öffnet sich der Project Explorer des Spring Initializr (Abbildung 2-3). Der Initializr zeigt die Projektstruktur und die Build-Datei, die in das komprimierte (.zip) Projekt eingefügt wird, das Sie gleich herunterladen werden. Sie können sich die Verzeichnis-/Paketstruktur, die Datei mit den Eigenschaften der Anwendung (Properties; mehr dazu später) und die Projekteigenschaften und Abhängigkeiten anschauen, die in Ihrer Build-Datei festgelegt sind: Da wir für dieses Projekt Maven benutzen, ist unsere Build-Datei pom.xml.

Abbildung 2-3: Der Project Explorer des Spring Initializr

Damit lassen sich schnell und praktisch Projektkonfiguration und Abhängigkeiten überprüfen, bevor Sie Ihr brandneues, leeres Projekt herunterladen, extrahieren und in Ihre IDE laden.

Eine weitere kleine Eigenschaft des Spring Initializr, die aber dennoch von vielen Entwicklern willkommen geheißen wurde, ist der Dark-Modus. Indem Sie auf den Dark UI-Umschalter oben auf der Seite klicken (Abbildung 2-4), wechseln Sie in den Dark-Modus des Initializr. Dieser bleibt dann bis zum erneuten Umschalten auch der Standardmodus für spätere Besuche auf der Seite. Es ist nur eine Kleinigkeit, aber wenn Sie Ihre Maschine generell im Dark-Modus betreiben, ist es sinnvoll, dies auch beim Initializr zu machen. Es soll schließlich Spaß machen, wiederzukommen!

Abbildung 2-4: Der Spring Initializr im Dark-Modus!

Abgesehen von der Hauptanwendungsklasse und ihrer Hauptmethode sowie einem leeren Test generiert der Spring Initializr keinen Code für Sie, sondern er generiert das Projekt nach Ihren Anweisungen. Diese Unterscheidung ist klein, aber wichtig: Die Codegenerierung erzeugt völlig unterschiedliche Ergebnisse und bremst Sie oft in dem Augenblick aus, in dem Sie beginnen, Änderungen vorzunehmen. Durch das Generieren der Projektstruktur einschließlich der Build-Datei mit den angegebenen Abhängigkeiten bietet Ihnen der Initializr einen guten Ausgangspunkt für den Code, den Sie brauchen, um die Spring-Boot-Autokonfiguration wirksam zu nutzen. Die Autokonfiguration verleiht Ihnen Superkräfte, ohne Sie zu behindern.

Klicken Sie dann auf den Generate-Button, um Ihr Projekt zu generieren, zu verpacken und herunterzuladen, damit Sie es an der gewünschten Stelle auf Ihrem lokalen Rechner speichern können. Gehen Sie dann zu der heruntergeladenen .zip-Datei und packen Sie sie aus, um die Entwicklung Ihrer Anwendung vorzubereiten.

Rauf auf die Kommandozeile

Falls Sie sich am liebsten auf der Kommandozeile herumtreiben oder die Projekterzeugung irgendwann einmal per Skript erledigen wollen, ist das Spring Boot Command Line Interface (CLI) genau das Richtige für Sie. Das Spring Boot CLI besitzt viele erstaunliche Fähigkeiten, doch zunächst einmal wollen wir uns auf die Erzeugung eines neuen Boot-Projekts beschränken.

Das Spring Boot CLI installieren

Am einfachsten lässt sich das Spring Boot CLI über SDKMAN! installieren – genau wie Ihr JDK, die Kotlin-Dienstprogramme und mehr. Sie können im Terminal-Fenster

sdk list

ausführen, um die Pakete zu sehen, die für die Installation zur Verfügung stehen; Abbildung 2-5 zeigt die Darstellung im Spring Boot CLI. Anschließend führen Sie

sdk list springboot

aus, um die verfügbaren Versionen des Spring Boot CLI zu sehen. Die neueste (aktuelle) Version installieren Sie mit

sdk install springboot

Falls Sie mit dem SDKMAN!-Befehl sdk install <tool> <versionsidentifikator> keine spezielle Versionsangabe machen, installiert SDKMAN! üblicherweise die neueste empfohlene Produktionsversion der Sprache/des Werkzeugs. Das kann für die verschiedenen unterstützten Pakete unterschiedliche Dinge bedeuten; so wird z.B. die neueste Long-Term-Support-(LTS-)Version von Java installiert und nicht eine neuere (Nicht-LTS-)Version, die vielleicht vorhanden ist. Das liegt daran, dass alle sechs Monate eine neue nummerierte Version von Java veröffentlicht und regelmäßig eine Version zur LTS-Version erklärt wird – was bedeutet, dass es oft eine oder mehrere neuere Versionen gibt, die jeweils offiziell nur für sechs Monate unterstützt werden (zum Ausprobieren und Testen von Funktionen oder vielleicht sogar für Produktions-Deployments), während eine bestimmte LTS-Version vollständig unterstützt wird, also Updates und Bug-Fixes erfährt.

Diese Anmerkung ist sehr allgemein, und es kann Abweichungen zwischen den einzelnen JDK-Anbietern geben. Die meisten halten sich allerdings mehr oder weniger an die üblichen Vereinbarungen. Den Einzelheiten wurden schon ganze Talks gewidmet, allerdings ist das für unsere Zwecke hier nicht von Belang.

Abbildung 2-5: Das Spring Boot CLI auf SDKMAN!

Nach dem Installieren des Spring Boot CLI können Sie mit dem folgenden Befehl das gleiche Projekt erzeugen wie mit dem Initializr:

spring init

Um das gezippte Projekt in einem Verzeichnis namens demo zu entpacken, führen Sie diesen Befehl aus:

unzip demo.zip -d demo

Moment mal, wieso ist das so einfach? Die Antwort: Standardwerte. Das Spring CLI verwendet die gleichen Standardeinstellungen wie der Spring Initializr (Maven, Java und so weiter), sodass Sie nur für solche Werte Argumente angeben müssen, die Sie ändern wollen. Legen wir einmal speziell Werte für einige dieser Standardwerte fest (und nutzen einen hilfreichen Dreh für die Extraktion des Projekts), um besser zu sehen, wie das geht:

spring init -a demo -l java --build maven demo

Wir initialisieren auch hier ein Projekt mit dem Spring CLI, geben aber nun die folgenden Argumente vor:

-a demo

(oder

--artifactId demo

) erlaubt es uns, eine Artefakt-ID für das Projekt anzugeben; wir nennen sie hier »demo«.

-l java

(oder

--language java

) lässt uns Java, Kotlin oder Groovy

1

als primäre Sprache für das Projekt festlegen.

--build

ist das Flag für das Build-System-Argument; gültige Werte sind

maven

und

gradle

.

-x demo

verlangt, dass das CLI die resultierende

.zip

-Projektdatei extrahiert, die vom Initializr zurückgegeben wird; beachten Sie, dass das

-x

optional ist und dass die Angabe einer Textbezeichnung ohne Erweiterung (wie hier) dankenswerterweise als Verzeichnis interpretiert wird, in dem die extrahierte Datei abgelegt werden soll.

All diese Optionen können Sie sich anschauen, wenn Sie auf der Kommandozeile spring help init ausführen.

Beim Festlegen der Abhängigkeiten werden die Dinge etwas komplizierter. Wie Sie sich vorstellen können, ist die Leichtigkeit einer Auswahl aus dem »Menü«, wie es der Spring Initializr bietet, kaum zu schlagen. Allerdings ist die Flexibilität des Spring CLI wiederum ausgesprochen praktisch, wenn es um einen schnellen Einstieg, um Skripte und um die Erstellung von Pipelines geht.

Und noch etwas: Das CLI greift standardmäßig auf den Initializr zurück, um dessen Fähigkeiten zur Projekterstellung auszunutzen. Das bedeutet, dass es im Prinzip egal ist, über welchen Mechanismus (CLI oder die Initializr-Webseite) Sie Projekte anlegen – sie sind in beiden Fällen identisch. Diese Konsistenz ist absolut entscheidend, wenn direkt die Fähigkeiten des Spring Initializr verwendet werden sollen.

Gelegentlich jedoch kontrolliert eine Organisation sehr genau, welche Abhängigkeiten ihre Entwickler benutzen dürfen, um Projekte zu erstellen. Um ganz ehrlich zu sein, macht mich eine solche Herangehensweise ziemlich traurig. Sie wirkt restriktiv und behindert die Agilität der Organisation sowie ihre Fähigkeit, auf die Benutzer/den Markt reagieren zu können. Wenn Sie in einer solchen Organisation sind, erschwert es Ihnen einfach nur Ihre Arbeit.

Es ist allerdings in einem solchen Fall möglich, Ihren eigenen Projektgenerator herzustellen (sogar das Repository für den Spring Initializr zu klonen) und diesen direkt über die resultierende Webseite zu benutzen … oder nur den REST-API-Teil aufzugreifen und diesen vom Spring CLI aus zu verwenden. Fügen Sie dazu einfach diesen Parameter zu den bereits gezeigten Befehlen hinzu (Sie müssen natürlich Ihre eigene URL einsetzen):

--target https://insert.your.url.here.org

In Integrated Development Environments (IDEs) bleiben

Ganz egal, wie Sie Ihr Spring-Boot-Projekt erzeugen – irgendwann müssen Sie es öffnen und irgendwelchen Code schreiben, um eine sinnvolle Anwendung zu erhalten.

Es gibt drei große IDEs und zahllose Texteditoren, die Sie als Entwickler ganz anständig unterstützen. Zu den IDEs gehören unter anderem Apache NetBeans (https://netbeans.apache.org/), Eclipse (https://www.eclipse.org/) und IntelliJ IDEA (https://www.jetbrains.com/idea). Alle drei sind Open-Source-Software (OSS) und alle drei sind in vielen Fällen kostenlos.2

In diesem Buch benutze ich wie in meinem normalen Alltag IntelliJ Ultimate Edition. Bei der Auswahl einer IDE gibt es eigentlich keine falschen Entscheidungen. Es ist eher eine Frage der persönlichen Vorlieben (oder unternehmerischen Vorgaben). Nehmen Sie deshalb das, was am besten zu Ihnen passt. Die meisten Konzepte lassen sich relativ gut auf eines der anderen großen Systeme übertragen.

Es gibt außerdem verschiedene Editoren, die unter den Entwicklern eine große Gefolgschaft gefunden haben. Manche, wie Sublime Text (https://www.sublimetext.com/), sind kostenpflichtige Anwendungen, die aufgrund ihrer Qualität und Langlebigkeit beliebt sind. Andere, neuere Kandidaten in diesem Bereich, wie Atom (https://atom.io/) (erstellt von GitHub, das inzwischen zu Microsoft gehört) und Visual Studio Code (https://code.visualstudio.com/) (kurz VSCode, erstellt von Microsoft), gewinnen sehr schnell neue Fähigkeiten und auch loyale Anhänger.

In diesem Buch verwende ich gelegentlich VSCode oder sein Gegenstück VSCodium (https://vscodium.com/), das auf derselben Codebasis beruht, aber keine Telemetrie-/Tracking-Funktionen enthält. Um einige der Funktionen zu unterstützen, die die meisten Entwickler von ihrer Entwicklungsumgebung erwarten und/oder verlangen, füge ich zu VSCode/VSCodium die folgenden Erweiterungen hinzu:

Spring Boot Extension Pack (Pivotal) (https://oreil.ly/SBExtPack)

Dieses enthält mehrere weitere Erweiterungen, darunter Spring Initializr Java Support, Spring Boot Tools und Spring Boot Dashboard, die das Erzeugen, Bearbeiten beziehungsweise Verwalten von Spring-Boot-Anwendungen in VSCode ermöglichen.

Debugger for Java (Microsoft) (https://oreil.ly/DebuggerJava)

Abhängigkeit des Spring Boot Dashboard.

IntelliJ IDEA Keybindings (Keisuke Kato) (https://oreil.ly/IntellijIDEAKeys)

Da ich vor allem IntelliJ benutze, erleichtert mir dies den Wechsel zwischen den beiden.

Language Support for Java™ (Red Hat) (https://oreil.ly/JavaLangSupport)

Abhängigkeit von Spring Boot Tools.

Maven for Java (Microsoft) (https://oreil.ly/MavenJava)

Ermöglicht die Benutzung von Maven-basierten Projekten.

Es gibt noch andere Erweiterungen, die Ihnen beim Verwenden von XML, Docker oder anderen ergänzenden Technologien behilflich sind. Die hier genannten sind jedoch für unsere Zwecke erforderlich.