Nach seinem Studium der Physik und anschließender Promotion Wechsel in die IT-Branche. Seit mehr als 20 Jahren als Entwickler, Berater und Projektleiter vorwiegend im Bereich Java und JavaScript unterwegs. Parallel dazu in der Entwicklung und Durchführung von hochwertigen Seminaren für die Integrata im Einsatz.
Obwohl der Begriff NoSQL schon im Jahre 1998 (https://de.wikipedia.org/wiki/NoSQL) geprägt wurde und mittlerweile im allgemeinen IT-Sprachgebrauch etabliert ist, ist eine genaue Definition auch heute noch nicht eindeutig etabliert.
In dieser Reihe möchte ich das Versionsverwaltungssystem Git vorstellen, das auch für Java-Seminare der Integrata benutzt wird, um den Teilnehmern eine komfortable Arbeitsumgebung zu definieren. Weiterhin werden die Musterbeispiele für verschiedene Seminare über öffentliche Git-Server bereitgestellt.
Dieser erste Teil liefert eine Kurzeinführung in das elementare Arbeiten mit Git.
Teil 2 stellt das Eclipse-PlugIn für Git vor, da Eclipse die Standard-Entwicklungsumgebung bei der Integrata ist.
Teil 3 schließlich zeigt, wie Git in Java-Seminaren benutzt werden kann.
Ein Versionsverwaltungssystem ermöglicht es, verschiedene Stände eines Dateibestands eindeutig und reproduzierbar abzulegen. Solche Systeme sind innerhalb eines Software-Projekts unverzichtbar, um Quellcodes und Konfigurationsdateien abzulegen. Git ist ein so genanntes Verteiltes Source Code Management System. Das bedeutet, dass auch ohne Server-Anbindung auf jedem Rechner mit Git-Installation ein vollständiges Versionsverwaltungssystem, ein so genanntes Git-Repository, zur Verfügung steht. Ein Repository besteht aus einer internen Dateiablage (das Verzeichnis .git), das enthaltende Verzeichnis ist der Arbeitsbereich des Git-Projekts.
“Vollständig” bedeutet, dass der Anwender unter anderem die folgenden Befehle benutzen kann, die typisch für das Arbeiten mit einem Versionsverwaltungssystem sind:
commitcommit einen Schritt voran.add erst einmal für eine Änderung vorgemerkt werden.branchcheckout <branch-name>merge <branch-to-merge>statusDie Benutzung eines gemeinsamen Servers ist auch bei Git sinnvoll möglich. Im Internet sind Git-Server nach Anmeldung frei verfügbar, in denen dann beliebig viele Repositories angelegt werden können. Bekannt sind hier GitHub und GitLab.
Ist auf einem Git-Server ein Repository eingerichtet, wird kann dieses bei vorhandener Internet-Verbindung als lokales Repository “gecloned” werden.
Zur Verwendung eines Remote Repositories werden zusätzliche Befehle benötigt:
clone <directory or url>pullpushpusherst einmal der potenziell geänderte Stand gepulled werden. Dann werden die Stände lokal konsolidiert und anschließend erst hochgepushed.git clone https://github.com/JavacreamTraining/simple.gitgit status zeigt die Änderung an.git commit -a -m "my commit message" stellt die Änderungen unter Versionskontrolle.git status zeigt die Konsistenz zwischen Workspace und Repository an, es gibt keine nicht committeten Stände.git push wird hier nicht funktionieren, das Repository ist auf dem Server aus nahe liegenden Gründen geschützt.Im nächsten Teil wird das Arbeiten mit Git durch die Verwendung des Eclipse-Plugins vereinfacht werden.
Mit der Programmiersprache Swift hat Apple ein modernes Werkzeug für die Anwendungsentwicklung für Mac und iOS bereit gestellt. Diese Sprache löst das von vielen Entwicklern als etwas gewöhnungsbedürftig und sperrig betrachtete Objective C ab. Mit der aktuellen Version 3 steht eine erste vollständige und unabhängige Implementierung zur Verfügung. Die anstehende Version 4 wird weitere Features einführen, jedoch keine Änderungen an der Core-Sprache mehr vornehmen.
Swift wurde von Apple als Open Source-Initiative freigegeben und steht damit auch für andere Plattformen zur Verfügung, z.B. für Ubuntu. Eine durchaus beachtenswerte Abkehr von der bisherigen Abschottung der Apple-Produkte. Allerdings gilt dies natürlich nur für den Kern der Sprache, die App-Programmierung muss aus Lizenz-Gründen weiterhin unter Apple Hardware und Betriebssystem erfolgen. Diese Einschränkung ist für diesen Artikel allerdings nicht relevant, da ich mich hier bewusst auf den Vergleich der Programmiersprachen konzentrieren möchte; für einen (durchaus interessanten!) Vergleich von Google Android und Apple Swift gibt es andere Artikel.
Swift vereinigt etablierte Konzepte aus Sprachen wie Java, C#, JavaScript und natürlich auch Objective C und ergänzt diese durch eigene Ideen. Damit finden Programmierer einesteils recht viel Bekanntes, aber eben auch unerwartete und damit überraschende Konstrukte. Hier möchte ich auf die Unterschiede zu Java eingehen, die aus meiner Erfahrung heraus relevant sind.
Für Java-Entwickler ist Swift auch deshalb interessant, weil einige Konzepte durchaus auch in einer zukünftigen Java-Version Einzug halten könnten. Weiterhin gibt es doch eine Reihe von Besonderheiten, die den Einstieg in Swift erschweren könnten.
Swift ist wie Java streng und statisch typisiert. Damit prüft der Swift-Compiler, dass einer einmal deklarierten Variable kein Wert eines anderen Datentyps zugewiesen werden kann.
Allerdings ist eine Typ-Angabe bei der Deklaration optional; der Typ kann meistens aus dem Typen der Zuweisung bestimmt werden:
var message = "Hello" //message is a String message = "Hello!" //OK //message = 42 //Compiler Error var message2:String //No type inference
Sehr gut gelöst ist meiner Meinung nach der Umgang mit Null-Werten, in Swift nilgenannt. Einer Variablen muss ein Nicht-Null-Wert zugewiesen werden, es sei denn, sie wird explizit als Optional-Typ deklariert:
var message = "Hello" //message non optional String //message = nil //Compiler error var message2:String? = "Hello" //message2 an optional String message2 = nil //OK
Optionals sind in Swift eigene Typen, so dass der Compiler bei Zuweisungen die normale Typ-Prüfung durchführt und Fehler erkennt:
//message = message2 //Compiler error: String? not of type String
Optionale Typen müssen vor ihrer weiteren Verwendung “ausgepackt”=unwrapped werden. Dafür gibt es in Swift zwei Möglichkeiten:
!-Operatorif -let -Konstruktion:message = message2!
if let x = message2 {
print (x)
}
Obwohl diese Sequenzen für einen Java-Entwickler erst einmal merkwürdig aussehen liegt der Vorteil auf der Hand: Bereits der Compiler erkennt Zuweisungen von Null-Werten, so dass der Entwickler auf null-Prüfungen oder das Fangen einer NullPointerException verzichten kann.
Und dann haben wir noch das “Optional Chaining” beim Zugriff auf Eigenschaften eines Objekts:
if (message2!.hasPrefix("H"){ //Unsafe
//...
}
if (message2?.hasPrefix("H"){ //Safe
//...
}
Falls message2 nil sein sollte wird die hasPrefix-Methode nicht ausgeführt.
Swift kennt zwei unterschiedliche Definitionen eines benutzerdefinierten Datentyps: Klassen und Strukturen.
struct Address{
var city: String, street: String
}
class Person{
private var name:String
init(name: String){
self.name = name
}
var Name: String{
get {
return name
}
set {
print ("setting lastname...")
name = newValue
}
}
func info() -> String {
var greeting = "Hello, my name is \(name)"
return greeting
}
}
Während Instanzen von Klassen wie in Java stets über Referenzen angesprochen werden, werden Strukturen immer als Werte angesehen:
let address1 = Address(city: "München", street: "Marienplatz") let address2 = address1 let person1 = Person(name: "Hugo") let person2 = person1
Ganz besonders verwirrend für Java-Entwickler ist, dass alle Collections-Implementierungen in Swift als Strukturen realisiert wurden!
Weitere Besonderheiten sind eher unter “syntactic sugar” zu sehen:
get– und set-BlöckeAlle Klassen und Strukturen sind in Swift “Open for Extension”. Das bedeutet, dass auch ohne Vererbung vorhandene Klassen jederzeit erweitert werden können. Nur zur Klarstellung: Dies gilt selbstverständlich auch für die Klassen der Standard-Bibliothek!
Zur Definition wird das Schlüsselwort extension benutzt. Im Folgenden eine (zugegebenermaßen triviale) Erweiterung der Person-Klasse sowie ein neuer Konstruktor für String:
extension Person{
func sayHello{
return "Hello",
}
}
extension String{
init?(_ address: Address){
self.init("Die Adresse \(address.city)")
}
}
Extensions können eine Klasse nicht mit neuen Attributen ausstatten. get– und set-Blöcke können jedoch verwendet werden.
func func1(message: String){
print(message)
}
func1(message: "Hello")
//func1("Hello) //compiler error
func func2(message m: String){
print(m)
//print (message)
}
func2(message: "Hello")
//func2("Hello) //compiler error
//func2(m: "Hello) //compiler error
Sollen die Parameter nicht benannt sein wird der Unterstrich als öffentlicher Name benutzt:
func func3(_ message: String){
print(message)
}
func3("Hello")
//func3(message: "Hello") //compiler errorprotocol, nicht interface.let multiplier = 3.0 let message = "\(multiplier) times 2.5 is \(Double(multiplier) * 2.5)" // message is "3 times 2.5 is 7.5"
func + (left: Int, right: Int) -> Int{ //just for fun
return left - right
}
func == (left: Person, right: Person) -> Bool{ //all people are equal
return true
}
func + (left: Person, right: Person){ //adding to people = marriage, suggestions for '-'?
left.marry(right)
}infix operator ❤ {associativity left precedence 200}
func ❤ (left: Person, right: Person) -> Person{
left.marry(right)
return left
}
//In action:
rainer ❤ carola
Die im Artikel beschriebenen Code-Fragmente stehen über meinen GitHub-Account zur freien Verfügung und können gerne für eigene Experimente benutzt werden. Die Sourcen gibt es hier.
Die Beispiele benötigen eine Swift-Installation, ich habe hierzu die Ubuntu-Installation benutzt.
Was steckt eigentlich hinter dem “Project Lombok”? Jeder Java-Entwickler kennt das Problem bei der Erstellung einer einfachen Datenstruktur. Die eigentliche Modellierung und Definition der Attribute einer Klasse ist erst einmal einfach:
public class Person {
private String name;
private int height;
}
Anschließend müssen dann aber erst einmal aufwändig weitere notwendige Elemente geschrieben werden:
public class Person {
private String name;
private int height;
@Override
public String toString() {
return "Person [name=" + name + ", height=" + height + "]";
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + height;
result = prime * result + ((name == null) ? 0 : name.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Person other = (Person) obj;
if (height != other.height)
return false;
if (name == null) {
if (other.name != null)
return false;
} else if (!name.equals(other.name))
return false;
return true;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
public String getName() {
return name;
}
public Person(String name, int height) {
super();
this.name = name;
this.height = height;
}
}
Ohne die Hilfe einer Entwicklungsumgebung wie Eclipse, IntelliJ oder ähnliches wäre dieser Aufwand absurd hoch!
Die Intention des Lombok-Projekts ist es, diesen Aufwand zu vermeiden. Insbesondere bei Änderungen der Datenstruktur müssten ja sonst alle diese Aktionen nochmals neu ausgeführt werden, damit Inkonsistenzen vermieden werden. Mit Lombok muss der Entwickler nur noch Annotationen definieren, die bei jedem Compiler-Lauf neu ausgewertet werden und folglich den aktuellen Stand repräsentieren.
Betrachten wir doch einmal das Outline der oben dargestellten Klasse Person und vergleichen diese mit dem der Klasse LombokPerson
Selbst bei genauer Betrachtung lässt sich hier, außer dem Namen der Klasse, kein Unterschied erkennen. Nun aber der Quellcode der Klasse LombokPerson:
import lombok.AllArgsConstructor;
import lombok.Data;
@Data
@AllArgsConstructor
public class LombokPerson {
private final String name;
private int height;
}Das ist tatsächlich alles! Keine Konstruktoren, keine Setter etc. Das alles wurde automatisch an Hand der Annotationen erzeugt.
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>0.9.2</version>
</dependency>
</dependencies>
Mit Lombok steht meiner Meinung nach ein wirklich sinnvolles Werkzeug zur Verfügung, das den Aufwand bei der Erstellung von Java-Datenklassen deutlich verringert. Programmierern, die sich auch im C#-, Swift oder Groovy-Umfeld bewegen, wird diese Art der Entwicklung sehr bekannt vorkommen. Java ist in diesem Bereich selbst in der Version 8 immer noch ziemlich altbacken, überdies ist eine echte Verbesserung leider auch in der Java 9 -Roadmap nicht erkennbar. Lombok wird deshalb auch noch mittelfristig sinnvoll eingesetzt werden.
Mit den “Experimental Features” werden weitere hochinteressante Elemente eingeführt, die allerdings teilweise einen Überlapp zur Aspekt-orientierten Programmierung aufweisen. Ob diese Annotationen in eigenen Projekten sinnvoll benutzt werden können muss individuell entschieden werden. Nicht vergessen: Project Lombok ist Open Source und folglich Community-getrieben! Welche Richtung dieses Projekt in Zukunft nehmen wird kann deshalb jeder aktiv mit beeinflussen.
Bildnachweis: pixabay ch1310 CC0 Public Domain
Im letzten Teil dieser Serie programmieren wir einen RESTful Web Service mit Spring Boot und stellen diesen über ein Docker-Image zur Verfügung. Dabei stützen wir uns auf den im dritten Teil beschriebenen Build-Prozess.
Mit Hilfe von Spring Boot können auch komplexe Server-Anwendung als einfaches Java-Archiv ausgebracht und gestartet werden. Dazu werden durch einen ausgefeilten Build-Prozess die Anwendungsklassen zusammen mit allen notwendigen Server-Bibliotheken in ein einziges ausführbares Java-Archiv gepackt.
Der Build-Prozess selbst wird wie üblich mit Hilfe eines Maven-Parents definiert. Dieser wird von der Spring-Community zur Verfügung gestellt.
<project <groupId>org.javacream</groupId> <artifactId>org.javacream.training.spring-boot-docker</artifactId> <version>0.1.0</version> <packaging>pom</packaging> <name>Spring Boot Docker</name> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.1.RELEASE</version> <relativePath /> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>
Benutzen wie dieses POM als Parent für das im 3. Teil der Artikelreihe benutzten Parents, so haben wir den Docker- und den Spring-Boot-Build vereint. Mehr ist tatsächlich nicht zu tun! Im folgenden ist die vollständige Parent-POM dieser Anwendung gegeben, ergänzt um die (hier noch nicht benutzten) Abhängigkeiten zu Spring Data JPA und einer MySQL-Datenbank.
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.javacream.training.docker</groupId>
<artifactId>org.javacream.training.docker.parent</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.1.RELEASE</version>
<relativePath />
</parent>
<properties>
<docker.namespace.prefix>javacream</docker.namespace.prefix>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<!-- tag::plugin[] -->
<plugin>
<groupId>com.spotify</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>0.4.11</version>
<configuration>
<imageName>${docker.image.prefix}/${project.artifactId}</imageName>
<dockerDirectory>src/main/docker</dockerDirectory>
<resources>
<resource>
<targetPath>/</targetPath>
<directory>${project.build.directory}</directory>
<include>${project.build.finalName}.jar</include>
</resource>
</resources>
</configuration>
</plugin>
<!-- end::plugin[] -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/libs</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>0.4.11</version>
<configuration>
<imageName>${docker.namespace.prefix}/${project.artifactId}</imageName>
<dockerDirectory>src/main/docker</dockerDirectory>
<resources>
<resource>
<targetPath>/</targetPath>
<directory>${project.build.directory}</directory>
<include>${project.build.finalName}.jar</include>
</resource>
<resource>
<targetPath>/</targetPath>
<directory>${project.build.directory}</directory>
<include>libs/*.jar</include>
</resource>
</resources>
<imageTags>
<imageTag>${project.version}</imageTag>
<imageTag>latest</imageTag>
</imageTags>
</configuration>
</plugin>
</plugins>
</build>
<distributionManagement>
<repository>
<uniqueVersion>false</uniqueVersion>
<id>nexus</id>
<name>Corporate Repository</name>
<url>http://localhost:8081/repository/maven-releases/</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<uniqueVersion>true</uniqueVersion>
<id>nexus</id>
<name>Corporate Snapshots</name>
<url>http://localhost:8081/repository/maven-snapshots/</url>
<layout>legacy</layout>
</snapshotRepository>
</distributionManagement>
</project>
RESTful Web Services werden in Java meistens mit Annotationen realisiert. Dabei wird eine URL auf eine Java-Methodensignatur abgebildet. Dies erfolgt meistens durch Annotationen, entweder mit JAX-RS oder mit den RequestMappings aus Spring-MVC. Im folgenden Beispiel benutzen wir den zweiten Ansatz:
package org.javacream.training.rest.spring;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;
@SpringBootApplication
@RestController
public class Application {
@RequestMapping(path = "/echo/{message}", method = { RequestMethod.GET })
public String echo(@PathVariable("message") String message) {
return "Echoing from Server: " + message;
}
}
Diese Java-Klasse kann aus Eclipse heraus sofort gestartet werden und anschließend beispielsweise mit Hilfe des curl-Kommandos getestet werden:
curl -X GET http://localhost:8080/echo/Hello
Ein Maven-Build des Projekts erzeugt das Java-Archiv bzw. lädt es in das Artefakt-Repository
mvn package
mvn deploy
Ein Aufruf ist dann unter der Angabe des Java-Archivs möglich:
java -jar org.javacream.training.rest.spring.basic-0.1.0.jar
Natürlich kann das Archiv auch unbenannt werden, dann ist der Aufruf noch einfacher:
java -jar app.jar
Wichtig ist hier, dass das gebildete Artefakt alle notwendigen Bibliotheken mitbringt, um den Web Server für die http-Requests zu starten. Das Archiv ist vollständig.
Zum Erstellen des Docker-Images brauchen wir nun nur noch ein Dockerfile! Dessen Inhalt ist aus den vorherigen Ausführungen heraus allerdings schon fast trivial:
FROM openjdk:latest ADD org.javacream.training.rest.spring.basic-0.0.1.jar app.jar ENTRYPOINT java -jar app.jar
Der RESTful Web Service wird nun ganz normal gestartet:
docker run --rm javacream:org.javacream.training.rest.spring.basic:0.0.1
und könnte wieder über curl getestet werden.
Soll das Image noch auf das Artefakt-Repository geschoben werden genügt ein
mvn docker:push
Das funktioniert aber natürlich nur, wenn ein eigenes Repository betrieben wird. Aber auch dieses Problem ist bereits gelöst: Nexus und Artefactory unterstützen Docker ganz analog zu Java-Artefakten.
Damit steht das Image anderen Entwicklern, der Test&QS-Abteilung oder den System-Administratoren der Produktionsumgebung zur Verfügung.
Dieser Artikel ist der Abschluss meiner Reihe über “Docker und Java”. Wer mehr über den Einsatz von Java in einer Microservice-Systemarchitektur lesen möchte: Im Frühjahr 2017 erscheint eine Reihe von Artikeln zum Thema “Microservice-Architekturen mit Docker”.