Referenzen und Objekte

Objekt-orientierte Programmierung ist bekanntermaßen ein sehr verbreitetes Konzept zur Modellierung komplexer Anwendungen. Die Programmiersprache Java hat bereits seit ihrer Einführung 1995 dieses Konzept aufgenommen. Auch die Laufzeitumgebung, also die Java Virtual Machine (JVM) berücksichtigt dieses Konzept und implementiert deshalb ein Speichermodell, das auf Referenzen und Objekte ausgerichtet ist.

Stack und Heap

Der Speicher der Java Virtual Machine ist in einen Stack- und einen Heap-Bereich unterteilt.

Stack und Heap der JVM

Diese Unterteilung ist zwar etwas grob, genügt aber für die folgende Betrachtung völlig.

Jede Java-Methode bekommt ihren eigenen Stack-Bereich zugeordnet. Innerhalb des Stacks werden sämtliche lokalen Variablen abgelegt. Wie im Objekt-orientierten notwendig sind diese Variablen in Java stets Referenzen auf Objekte. Diese werden im Heap-Bereich abgelegt.

Dies sei am Beispiel der folgenden main-Methode aufgezeigt:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
}

Im Speicher der JVM ergibt sich das folgende Bild:

Die main-Methode mit den lokalen Variablen message und names

Methodenaufruf

Nun definieren wir eine zweite Methode, called, diesmal mit 2 Parametern

public static void called(String str, String[] list){

}
Die methoden called mit den beiden Parametern str und list

Diese Methode wird aus main heraus aufgerufen:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
}

Wie erfolgt nun jedoch die Übergabe der lokalen Variablen message und names in die Parameter str und list?

Wie werden die Parameter belegt?

Dazu wird die JVM die Werte der Referenzen als Kopie übergeben, also ein “CallByValue”-Verhalten auf der Ebene der Referenzen:

Copy By Value mit Referenzen

Im Endeffekt zeigen die Referenzen auf die selben Objekte im Heap.

Zuweisung von Werten

Was passiert aber nun, wenn in der aufgerufenen Methode den Parametern neue Werte zugewiesen werden? Hier ergibt sich ein feiner aber unglaublich wichtiger Unterschied: Belegen wir den Parameter str einfach mit einem neuen Wert, z.B. mit

str = "Goodbye";

so wird die Variable im Stack einfach mit einer Referenz auf das neue Objekt im Heap überschrieben:

Zuweisung eines neuen Wertes an den Parameter str

Wichtig hier ist, dass in der aufrufenden main-Methode die Variable message davon völlig unbeeinflusst bleibt.

Was passiert aber, wenn wir die Referenz auf das Array benutzen, um beispielsweise den Wert des zweiten Elements mit Index 1 auf “Paul” zu setzen?

list[1] ="Paul";

Nun ergibt sich ein anderes Bild:

Zuweisung eines neuen Wertes an das zweite Element der Liste

Hier ist klar ersichtlich, dass diese Änderung des Array-Objekts innerhalb der Methode called auch direkt Auswirkungen auf die aufrufende main-Methode hat: Nachdem die Methode called terminiert ist referenziert auch die Variable message auf das Array, dessen zweites Element nun auf “Paul” zeigt.

Also innerhalb von main

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
System.out.println(names[1]); //-> Paul
}

Zusammenfassung und Ausblick

Durch die Betrachtung des Speichermodells der Java Virtual Machine wird die Arbeitsweise eines Objekt-orientierten Programms unter Verwendung von Referenzen klar und verständlich. Das komplette Beispiel liegt als fertiges Eclipse-Projekt vor und enthält zusätzlich Konsolen-Ausgaben, die den Ablauf des Programms demonstrieren. Selbstverständlich kann aber auch der Eclipse-Debugger benutzt werden, um die Ausführung nachzuvollziehen.

Allerdings sind sicherlich auch noch einige Punkte nicht fundiert behandelt worden:

  • Das vorgestellte Speichermodell ist stark vereinfacht. Wie schaut es denn tatsächlich aus?
  • Was passiert eigentlich mit dem armen Objekt “Fritz”, das nun komplett losgelöst im Heap vorhanden ist?

Diese beiden Punkte werden in einem folgenden Artikel, der den Garbage Collector der JVM als Thema hat, behandelt.


Seminar zum Thema

Weiterlesen

Blockchain

Eine Blockchain mit Java

Eine Blockchain mit Java

Im vorherigen Artikel wurde die prinzipielle Arbeitsweise einer Blockchain allgemein diskutiert. Eine Blockchain mit Java zu implementieren ist prinzipiell nicht sonderlich schwer und wird im Folgenden gezeigt.

Einige Hinweise sind vorab notwendig, um beim Leser keine übertriebenen Erwartungen zu wecken:

  • Diese Java-Klassen alleine stellen natürlich kein funktionierendes verteiltes Datenbanksystem dar. Dazu fehlt das Netz der Server-Knoten.
  • Eine konkrete Validierung der Records, die in einen Block eingestellt wird erfolgt nur rudimentär. Dies ist selbstverständlich eine Anforderung, die aus einer fachlichen Spezifikation entnommen werden muss. Eine Blockchain für Gesundheitsdaten hat komplett andere Regeln als eine für Finanz-Transaktionen.
  • Komplett weggelassen wurde das Thema “Consense Modelle”, also beispielsweise ein “Proove of Work” wie beim Bitcoin-Mining.

Das Beispielprojekt

Die im Folgenden gezeigten Beispiele sind im GitHub-Account des Autoren abgelegt. Das Projekt ist frei verfügbar und kann für eigene Demonstrationen und Ergänzungen gerne benutzt werden.

Hashing

Zwingend notwendig für die Arbeit einer Blockchain ist die Bestimmung der hochwertigen Hashes. Dieses Problem ist in der Java-Distribution schon lange gelöst, dafür gibt es die Klasse MessageDigest.  Nachdem diese jedoch etwas sperrig in der Benutzung ist, wird das DigestUtil aus dem Apache Commons Codec-Projekt benutzt:

Placeholder

Der Test beweist, dass die Anforderungen an die Hash-Erzeugung erfüllt sind:

  • Unabhängig von der Länge der Eingangsdaten sind alle Hash-Werte gleich lang, nämlich 32 Zeichen.
  • Die Hash-Werte zweier minimal unterschiedlicher Eingangsdaten weisen keinerlei Ähnlichkeiten auf.
  • Der Wertebereich des Hashes ist so groß, dass zufällige Identitäten ausgeschlossen werden können.

 

Der Block

Die Implementierung eines für die Chain geeigneten Blocks ist tatsächlich sehr einfach. Ein Block enthält

  • die Daten, die für ein einfaches Beispiel beliebig sein können
  • den Hashwert des Vorgängers
  • einen eigenen Hashwert
  • einen Zeitstempel

Eine direkte Umsetzung zeigt folgende Klasse:

Placeholder

Eine korrekte Arbeitsweise beweist dieser Unit-Test:

Placeholder

Die Blockchain

Die Blockchain-Implementierung macht folgendes:

    • Die Klasse hält eine Liste von Blöcken
    • Eine add-Methode nimmt hinzuzufügende Daten entgegen. Diese werden exemplarisch validiert und, nach Erfolg, in einen Block umgesetzt. Dieser wird anschließend in der Liste hinzugefügt.
    • Mit Angabe eines Indexes kann ein bestimmter Datensatz wiederum gelesen werden.
    • Ebenso kann eine Liste aller Daten erhalten werden.
Placeholder

Im Endeffekt bildet die verkettete Liste der Blöcke einen Hash-Baum oder Merkle-Tree.

Auch hier zeigt ein Test das korrekte Funktionieren der Implementierung:

Placeholder

Der Versuch eines Angriffs

Wie kann nun ein Angriff auf diese Blockchain erfolgen? Bevor der Versuch eines Angriffs näher erläutert wird ist es aber wichtig, sich bewusst zu machen, dass die Informationen, die in der Chain abgelegt sind, in der Praxis auf vielen Knoten eines verteilten Systems abgelegt sein werden. Das bedeutet damit, dass der Angreifer seine Attacke nicht nur gegen einen Rechner fahren muss, sondern im Endeffekt gegen eine Majorität der Rechner. Dies macht die Sache schon deutlich komplexer. Andererseits müssen die Knoten ihre Daten untereinander synchronisieren, was durch Abhören der Netzwerkkommunikation einen erstmals durchaus vielversprechenden Angriffsvektor definiert.

Hat der Angreifer Zugriff auf einen oder mehrere Blöcke, so können die darin enthaltenen Informationen ausgelesen werden. Um ein Bloßlegen sensibler Daten zu verhindern, müssen damit die im Block enthaltenen Daten zusätzlich verschlüsselt werden. Das ist in dieser einfachen Implementierung nicht gegeben, in der Praxis aber ein eher einfach zu lösendes Problem.

Erweitern wir nun den Zugriff des Angreifers: Dieser hätte einen Server-Knoten komplett unter seine Gewalt bekommen. Und wir gehen noch weiter: Die Informationen der Blöcke sind im Klartext bekannt. Diese Situation wäre in einer klassischen Architektur vergleichbar mit einem korrumpierten Datenbank-Administrator, der den Datenbank-Host kontrolliert. Dass damit bereits beträchtlicher Schaden angerichtet ist, ist vollkommen klar. Aber fast noch schlimmer wäre es nun, die Daten manipulieren zu können. So könnte beispielsweise versucht werden, eine wichtige Information nachträglich zu ändern. Was muss der Angreifer alles machen:

  1. Der Block muss die geänderte Information gesetzt bekommen.
  2. Er muss einen neuen Hash erzeugen und auf diese Art und Weise einen komplett neuen, konsistenten Block erzeugen. Dies ist bereits die erste Komplikation.
  3. Nun muss der manipulierte Block in die Blockchain integriert werden. Und nun wird es wirklich kompliziert: Denn nicht nur der eine manipulierte Block muss geändert werden, sondern auch alle (!) Nachfolger. Denn diese beziehen sich auf einen Parent-Block, der so ja gar nicht mehr in der Chain enthalten ist. Der Aufwand für den Angreifer und damit die Wahrscheinlichkeit, dass die Manipulation entdeckt wird steigt bereits hier drastisch.
  4. Und zum Schluss muss der Angreifer die anderen Knoten des verteilten Systems “überzeugen”, diese Änderungen komplett zu übernehmen.

Schon der dritte Punkt ist so aufwändig zu realisieren, dass die Wahrscheinlichkeit eines Erfolgs des Angriffs drastisch sinkt. Punkt 4 übersteigt endgültig die Fähigkeiten eines realistischen Angreifers.

Der folgende Test simuliert einen Angreifer, der die Java-Anwendung angreift. Der Versuch ist erfolgreich bis zu Punkt zwei, aber mehr auch nicht:

Placeholder

Ausblick

Um ein funktionierendes, auf Blockchain-Technologie basierendes System in Betrieb nehmen zu können fehlen noch

  • Das verteilte System mit den kommunizierenden Knoten
  • Authentifizierung, Autorisierung und Verschlüsselung
  • Eine Implementierung einer fachlich konsistenten Validierung der Block-Daten
  • Und schließlich noch eine Logik für fachliche Abfragen.

 

 

Bild von analogicus auf Pixabay

 

 

Weiterlesen

Swift und Java

Java und Apple Swift

Apple Swift – Eine moderne Programmiersprache

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.

Swift und Java – Welche Konzepte sind interessant?

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.

Konsequente Type Inference

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

Optionals

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:

  • Explizites Unwrap mit dem !-Operator
  • Sicheres Unwrap über die if -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.

Klassen und Strukturen in Swift

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
Swift - Der Unterschied zwischen Strukturen und Klassen
Der Unterschied zwischen Strukturen und Klassen

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:

  • Einfache Definition von Properties durch get– und set-Blöcke
  • Bei Strukturen werden die Konstruktoren automatisch angelegt

Extensions

Alle 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.

Verschiedenes

  • Neben Klassen und Strukturen unterstützt Swift auch Enums und Tuples
  • Als Zeichen für Namen von Variablen oder Funktionen können beliebige Unicode-Zeichen benutzt werden.
  • Funktionsparameter haben eine  internen und gegebenenfalls einen öffentlichen Namen, der beim Aufruf mitgegeben werden muss:
    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 error
  • Die Swift-Installation enthält eine REPL, so dass Sequenzen und einfache Anwendungen auch ohne Installation einer Entwicklungsumgebung ausgeführt werden können.
  • Schnittstellen heißen in Swift protocol, nicht interface.
  • Mit der String Interpolation werden Variablen bzw. Ausdrücke direkt in Zeichenketten ausgewertet:
let multiplier = 3.0
let message = "\(multiplier) times 2.5 is \(Double(multiplier) * 2.5)"
// message is "3 times 2.5 is 7.5"
  • Operatoren können jederzeit geändert oder für eigene Datentypen definiert werden
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)
}
  • Auch neue Operatoren sind einfach zu deklarieren. So wird im folgenden Beispiel das Unicode-Zeichen für das Herz-Symbol als Operator zwischen zwei Personen definiert:
infix operator ❤ {associativity left precedence 200}

func ❤ (left: Person, right: Person) -> Person{
    left.marry(right)
    return left
}
//In action:

rainer ❤ carola

 

Die Beispiele

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.


Seminar zum Thema

Weiterlesen

Project Lombok - Java scharf gewürzt

Project Lombok – Java Klassen scharf gewürzt

 Die Motivation hinter Project Lombok

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:

  • Getter- und Setter-Methoden
  • Konstruktoren
  • hashCode und equals
  • toString
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!

Ausschnitt des Kontext-Menüs zur Code-Generierung in Eclipse
Ausschnitt des Kontext-Menüs zur Code-Generierung in Eclipse

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.

Ein Beispiel mit Project Lombok

Betrachten wir doch einmal das Outline der oben dargestellten Klasse Person und vergleichen diese mit dem der Klasse LombokPerson

Ein Vergleich der Struktur zweier Klassen zeigt keine Unterschiede
Ein Vergleich der Struktur zweier Klassen

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.

Details zur Arbeitsweise

  • Lombok stellt einen Annotation Processor zur Verfügung, der die notwendigen Code-Elemente automatisch erstellt. Dafür ist es nur notwendig, die lombok.jar dem Projekt hinzuzufügen und über die IDE das Annotation Processing zu aktivieren. Dann wird der Code generiert und anschließend compiliert.
  • Falls der Entwickler tatsächlich den generierten Java-Code benutzen möchte, kann hierfür delombok benutzt werden.
  • Die Code-Generierung kann durch die Angabe weitere Annotationen entsprechend fein angepasst werden. Damit können beispielsweise die in hashCode und equals auszuwertenden Attribute definiert oder der parameterlose Konstruktor generiert werden.
  • Zur Integration in Entwicklungsumgebungen steht in der lombok.jar eine ausführbare Installationsroutine zur Verfügung.

 

Der Installer für Project Lombok
Der Lombok-Installer, hier für eine Eclipse-Installation
  • Selbstverständlich kann Lombok auch in automatisierte Buildprozesse integriert werden. Für einen Maven-getriebenen Prozess genügt es beispielsweise, die Abhängigkeit auf Lombok in der POM einzutragen:
    <dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>0.9.2</version>
        </dependency>
    </dependencies>

     

Bewertung

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


Seminar zum Thema

Weiterlesen

DockerDuke

Docker und Java – Teil 3: Der Build-Prozess

Im zweiten Teil der Reihe wurden die notwendigen Werkzeuge vorgestellt und installiert. Nun werden wir den Build-Prozess für Java-Projekte und die Erstellung der Docker-Images zusammenführen.

Teil 3: Der Build-Prozess

Build von Java-Projekten mit Apache Maven

Apache Maven ist neben Apache Ant mit Ivy und Gradle ein Standard-Werkzeug, das zum automatisierten Erzeugen von Java-Archiven benutzt werden kann. Allen Werkzeugen gemeinsam ist das Dependency Management: Projekt-Abhängigkeiten werden in einer Konfigurationsdatei abgelegt und vom Build-Werkzeug automatisch aus einem Artefakt-Repository geladen. Repositories werden von verschiedenen Anbietern frei zugänglich im Internet betrieben. Maven Central ist das wahrscheinlich bekannteste Beispiel.

Um die selbst erzeugten Artefakte selbst verwalten zu können, werden im Unternehmen meistens eigene Server betrieben. Dazu existieren sofort einsetzbare Produkte wie Sonatype NexusJFrog Artefactory oder Apache Archiva.

Entscheiden wir uns für einen Maven-basierten Build-Prozess erfolgt die allgemeine Konfiguration des Build-Prozesses mit zwei Dateien:

  • Die settings.xml enthält die URL des Artefakt-Repositories und gegebenenfalls Authentifizierungs-Informationen
<settings>
	<mirrors>
		<mirror>
			<id>nexus</id>
			<mirrorOf>*</mirrorOf>
			<url>http://xxxxx/repository/maven-public/</url>
		</mirror>
	</mirrors>
	<repositories>
		<repository>
			<id>central</id>
			<url>http://central</url>
			<releases><enabled>true</enabled></releases>
			<snapshots><enabled>true</enabled></snapshots>
		</repository>
	</repositories>
	<pluginRepositories>
		<pluginRepository>
			<id>central</id>
			<url>http://central</url>
			<releases><enabled>true</enabled></releases>
			<snapshots><enabled>true</enabled></snapshots>
		</pluginRepository>
	</pluginRepositories>
	<servers>
		<server>
			<id>nexus</id>
			<username>xxx</username>
			<password>xxx</password>
	</server>
	</servers>
</settings>

 

Ein Parent-POM enthält neben allgemeinen Informationen für alle Build-Prozesse auch die Informationen zum Ausbringen der Artefakte in das Repository

<distributionManagement>
<repository>
<uniqueVersion>false</uniqueVersion>
<id>nexus</id>
<name>Corporate Repository</name>
<url>http://…</url>
</repository>
<snapshotRepository>
<uniqueVersion>true</uniqueVersion>
<id>nexus</id>
<name>Corporate Snapshots</name>
<url>http://…</url>
</snapshotRepository>
</distributionManagement>

 

Nach all diesen Vorbereitungen ist der Build-Prozess eines eigenen Projekts sehr einfach: Es wird ein Projekt-POM definiert, das im einfachsten Fall nur den Parent angeben muss.

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.javacream.training</groupId>
<artifactId>org.javacream.training.business</artifactId>
<version>1.0</version>
<parent>
<groupId>org.javacream.training.docker</groupId>
<artifactId>org.javacream.training.docker.parent</artifactId>
<version>1.0</version>
</parent>
</project>

 

Trotz dieser wirklich sehr einfachen Konfiguration kann das Java-Projekt sofort bis hin zu verschiedenen Phasen gebaut werden:

  • compile: Das Projekt wird kompiliert
  • package: Ein Java-Archiv wird im target-Verzeichnis des Projekts erzeugt
  • deploy: Das Archiv wird in das Unternehmens-Repository ausgebracht

So einfach funktioniert Maven!

Ein Maven System
Ein Maven System

Maven und Docker

Auch Docker definiert einen Build-Prozess: Images werden aus dem Dockerfile erzeugt. Was liegt also näher, als diesen Prozess mit Maven zu integrieren? Diese Idee wird durch Maven-PlugIns für Docker umgesetzt. Hierzu stehen sogar verschieden Produkte zur Auswahl:

 

  • Durch das Parent-POM ist die Integration dieser PlugIns für den Entwickler vollkommen transparent! Wird beispielsweise das Spotify-PlugIn in den Parent aufgenommen

 

<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>

 

so stehen nun neue Maven-Befehle zur Verfügung, insbesondere

  • docker:build: Erzeugen des Images aus dem Dockerfile des Projekts
  • docker:push: Pushen des Images in ein Docker-Repository

Damit ist die gewünschte Integration der Build-Prozesse durchgeführt. Und nachdem Nexus oder Artefactory neben Java-Artefakten auch Docker-Images verwalten können, ist unser System praktisch fertig! Dass die Quellcodes, das POM und das Dockerfile in einem Versionsverwaltungssystem abgelegt werden und auf ein Build-Server wie Jenkins die Builds automatisiert ablaufen lassen wird, ist selbstverständlich.

Die vollständige Parent-POM kann hier angezeigt werden:

<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>
	<properties>
		<docker.namespace.prefix>javacream</docker.namespace.prefix>
	</properties>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.12</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.logging.log4j</groupId>
			<artifactId>log4j-core</artifactId>
			<version>2.8</version>
		</dependency>
	</dependencies>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-dependency-plugin</artifactId>
				<version>3.0.0</version>
				<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>
				<version>3.6.1</version>
				<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>
						<imageTag>localhost:5000/${project.build.finalName}</imageTag>
					</imageTags>
				</configuration>
			</plugin>
		</plugins>
	</build>
	<distributionManagement>
		<repository>
			<uniqueVersion>false</uniqueVersion>
			<id>nexus</id>
			<name>Corporate Repository</name>
			<url>http://10.44.1.101:8081/repository/maven-releases/</url>
			<layout>default</layout>
		</repository>
		<snapshotRepository>
			<uniqueVersion>true</uniqueVersion>
			<id>nexus</id>
			<name>Corporate Snapshots</name>
			<url>http://10.44.1.101:8081/repository/maven-snapshots/</url>
			<layout>legacy</layout>
		</snapshotRepository>
	</distributionManagement>
</project>

 


Im vierten und letzten Teil wird dann programmiert: Wir erstellen einen Microservice auf Basis von Spring Boot!


Seminare zum Thema

 

Weiterlesen