MapStruct nutzt dabei die Annotationen, die auf den Java-Objekten angebracht sind, um automatisch Mapping-Code (Bean-Mappings) zu generieren. Das Framework generiert dabei standardmäßig Mappings zwischen Objekten mit gleichem Namen und Typ, es können aber auch eigene Mappings definiert werden. Dabei können auch komplexere Mappings erstellt werden, beispielsweise wenn Attribute in den Quell- und Zielobjekten unterschiedliche Namen haben oder wenn sie unterschiedliche Typen haben.

MapStruct ist sehr einfach zu verwenden und erfordert nur eine minimale Konfiguration. Es integriert sich nahtlos in das Build-System, da es als Annotation Processor fungiert und beim Kompilieren des Codes aufgerufen wird. Das Framework ist relativ schnell und hat einen geringen Overhead, da es keine Laufzeit-Abhängigkeiten hat.

Vorteile auf einem Blick

• Schnelle Ausführung durch Verwendung einfacher Methodenaufrufe anstelle von Reflexion (Bedeutet: Ein Programm kennt seine eigene Struktur und kann diese modifizieren)
• Kompilierzeit-Typensicherheit. Nur Objekte und Attribute, die einander zugeordnet sind – Es findet keine versehentliche Zuordnung einer Auftragsentität zu einem Kunden-DTO statt.
• In sich geschlossener Code – keine Laufzeit-Abhängigkeiten
• Eindeutige Fehlerberichte zur Erstellungszeit, wenn: 
  • Mappings unvollständig sind (Wenn nicht alle Zieleigenschaften gemappt sind)
  • Mappings fehlerhaft sind (Wenn es keine geeignete Mapping-Methode oder Typkonvertierung findet)
• Leicht zu debuggender Mapping-Code (Oder manuell editierbar, z. B. im Falle eines Fehlers im Generator)

Fazit

Zusammenfassend ist MapStruct ein leistungsfähiges und einfach zu bedienendes Framework, das die Entwicklung von Mapping-Code vereinfacht und beschleunigt. Vor allem, weil das Übertragen von Daten zwischen Objektmodellen meist eine wiederkehrende Aufgabe bei der Anwendungsentwicklung ist. Es ist eine gute Wahl, wenn man schnell und effizient Mapping-Funktionalitäten in Anwendungen integrieren möchte. Man kann es in Befehlszeilen-Builds (Maven, Gradle usw.) als auch in der bevorzugten IDE wie z.B. IntelliJ oder Eclipse verwenden.

Der Beitrag MapStruct – Schnelle und sichere Objektmapper für saubere und wartungsfreundliche Java-Anwendungen erschien zuerst auf CEOsBay.

Die Programmiersprache Java dient innerhalb der Java-Technologie vor allem zum Formulieren von Programmen. Diese liegen zunächst als reiner, menschenverständlicher Text vor, dem sogenannten Quellcode. Dieser Quellcode ist nicht direkt ausführbar. Erst der Java-Compiler, der Teil des Entwicklungswerkzeugs ist, übersetzt es in die Maschinensprache Java-Bytecode. Die Maschine, die diesen Bytecode ausführt, ist jedoch typischerweise virtuell. Folglich findet die Ausführung nicht direkt über die Hardware bzw. etwa einem Mikroprozessor ausgeführt, sondern durch entsprechende Software auf der Zielplattform.

Zweck der Virtualisierung ist die Plattformunabhängigkeit. Das Programm soll ohne weitere Änderung auf jeder Rechnerarchitektur laufen, wenn dort eine passende Laufzeitumgebung installiert ist. Oracle selbst bietet Laufzeitumgebungen für die Betriebssysteme Linux, macOS, Solaris und Windows an. Andere Hersteller lassen eigene Java-Laufzeitumgebungen für ihre Plattform zertifizieren. Auch in Autos, HiFi-Anlagen und anderen elektronischen Geräten wird Java verwendet.

Um die Ausführungsgeschwindigkeit zu erhöhen, werden Konzepte wie die Just-in-time-Kompilierung und die Hotspot-Optimierung verwendet. In Bezug auf den eigentlichen Ausführungsvorgang kann die JVM den Bytecode so interpretieren, bei Bedarf jedoch auch kompilieren und optimieren.

Eine kurze Zeitreise

Im Grunde genommen ist es eine Person, die für die Entstehung der objektorientierten Programmiersprache Java verantwortlich ist. James Gosling.

James Gosling schloss sein Studium an der University of Calgary im Jahr 1977 mit dem Bachelor of Science in Informatik ab. Sechs Jahre später erhielt er den Doktortitel. Während seiner Doktorarbeit schrieb er 1981 den ersten Emacs für Unix-Systeme in C. Seine Implementierung wurde unter dem Namen Gosling Emacs (Gosmacs) bekannt. Neben Compilern und Mailsystemen erfand er bei Sun Microsystems in den 80ern gemeinsam mit David S. H. Rosenthal auch das nicht mehr weiterentwickelte Windowing-System „NeWS (Network extensible Window System)“, welches ursprünglich unter dem Namen SunDew bekannt war.

Bei seiner Arbeit von 1984 bis 2010 arbeitete Gosling bei Sun Microsystems, in dieser Zeit entwarf er auch das originäre Design von Java. Den Grundstein für diese Programmiersprache hatte er bereits während seines Studiums gelegt. Dort entwickelte er auch eine virtuelle CPU, die P-Code als Maschinensprache ausführte. Das Konzept dieser Pseudo-Maschine übertrug Gosling später auf die architekturneutrale Ausführung weitverbreiteter Programme.

Im Jahr 2005 erhielt Gosling den Titel zum Chief Technical Officer der Produktentwicklung bei Sun Microsysems.

Java als Open Source bzw. Freie Software

Sun hatte zugesichert, die JDK unter der GNU General Public License zu veröffentlichen. mit der Übernahme durch Oracle wurde auch die offene Lizenzierung übernommen. Am 13. November 2006 haben sie erste Teile der JDK bereits mit dem Compiler javac und der Hotspot Virtual Machine als Open Source veröffentlicht. Zudem hat man mit OpenJDK eine Community-Seite eröffnet, mit deren Hilfe man die Entwicklung koordinierte. Am 8. Mai 2007 folgten große Teile des „Java-SE“-Quellcodes zum Erstellen eines JDK. Eine Ausnahme stellte solcher Code dar, für den Sun nicht die nötigen Rechte besaß, um diesen freizugeben. Dieser liegt somit nur in kompilierter Form vor. Ebenfalls kündigte Sun an, dass Entwicklungen auf Grundlage des OpenJDK das „Java Compatible“-Logo führen, wenn sie nach dem „Java Compatibility Kit“ (JCK) zertifiziert sind.

Zuvor hat man den Quelltext von Java unter anderem bei jedem JDK mitgeliefert und ermöglichte so zwar Einsicht, doch man durfte diesen nicht beliebig modifizieren. Aus diesem Grund gibt es neben den offiziellen JCP auch diverse unabhängige Vereinigungen, die es sich zum Ziel gesetzt haben, ein unter einer freien Open-Source-Lizenz gestelltes Java bereitzustellen. Die bekanntesten dieser Projekte sind Apache Harmony, Kaffe und das GNU-Classpath-Projekt gewesen. Gegenwärtig gibt es neben OpenJDK noch eine weitere große Implementierung, die aktuelle Java Releases veröffentlicht, Eclipse OpenJ9. Diese JVM-Implementierung hat IBM an die Eclipse Foundation übergeben. OpenJ9 steht mehrfachlizenziert unter EPL 2.0, Apache 2.0 und GNU 2.0 with Classpath Exception zur Verfügung. Darüber aber mehr in meinem Eclipse Beitrag.

Java ist mitunter eines der populärsten Programmiersprachen. In dem seit 2001 veröffentlichten TIOBE-Index lag Java bis 2020, konkurrierend mit C, stets auf den ersten beiden, seit 2021 mit zusätzlicher Konkurrenz von Python, auf den ersten drei Plätzen des Rankings. Nach dem RedMonk-Programmiersprachenindex 2019 liegt Java zusammen mit Python auf dem zweiten Platz nach JavaScript.

Das Grundkonzept von Java

Der Entwurf der Programmiersprache strebte hauptsächlich fünf Ziele an:

1. Sie soll eine einfache, objektorientierte, verteilte und vertraute Programmiersprache sein.
   Java ist im Vergleich zu anderen objektorientierten Programmiersprachen wie C++ oder C# einfacher, da es einen reduzierten Sprachumfang besitzt und beispielsweise Operatorüberladung und Mehrfachvererbung nicht unterstützt.
   
2. Sie soll robust und sicher sein.
   Viele der Designentscheidungen bei der Definition von Java reduzieren die Wahrscheinlichkeit ungewollter Systemfehler. Beispiele dafür sind die starke Typisierung, Garbage Collection, Ausnahmebehandlung sowie der Verzicht auf Zeigerarithmetik. Für die Sicherheit stehen Konzepte wie der Class-Loader, der die sichere Zuführung von Klasseninformationen zur Java Virtual Machine steuert und der Security-Manager, die sicherstellen, dass nur Zugriff auf Programmobjekte erlaubt wird, für die entsprechende Rechte vorhanden sind.
   
3. Sie soll architekturneutral und portabel sein.
   Java ist so entwickelt, dass dieselbe Version eines Programms prinzipiell auf einer beliebigen Computerhardware läuft, unabhängig von ihrem Prozessor oder anderen Hardwarebestandteilen. Zusätzlich zur Architekturneutralität ist es portabel. Folglich sind elementare Datentypen sowohl in ihrer Größe und der internen Darstellung als auch in ihrem arithmetischen Verhalten standardisiert. Beispielsweise ist ein float immer ein IEEE 754 Float von 32 Bit Länge. Dasselbe gilt beispielsweise auch für die Klassenbibliothek, mit deren Hilfe man eine vom Betriebssystem unabhängige GUI erzeugen kann.
   
4. Sie soll sehr leistungsfähig sein.
   Java hat aufgrund der Optimierungsmöglichkeit zur Laufzeit das Potenzial, eine bessere Performance als auf Compilezeit-Optimierungen begrenzte Sprachen (C++ und andere Sprachen) zu erreichen. Dem entgegen steht der Overhead durch die Laufzeitumgebung, sodass die Leistungsfähigkeit von beispielsweise C++-Programmen in einigen Kontexten übertroffen, in anderen aber nicht erreicht wird. Um die Leistungsfähigkeit zu gewährleisten, kann man in der Java Virtual Machine (JVM) die Performance messen.
   
5. Sie soll interpretierbar, parallelisierbar und dynamisch sein.
   Wie mehrfach erwähnt, finden die Kompilierung im maschinenunabhängigen Bytecode statt. Dieser wiederum kann auf der Zielplattform interpretiert werden. Die Java Virtual Machine interpretiert Bytecode, bevor sie es aus Performancegründen kompiliert und optimiert. Die Parallelisierbarkeit erreicht es durch die Unterstützung von Multithreading. Also durch den parallelen Ablauf von eigenständigen Programmabschnitten. Dazu bietet die Sprache selbst die Schlüsselwörter synchronized und volatile – Konstrukte, die das „Monitor & Condition Variable Paradigma“ von C. A. R. Hoare unterstützen. Die Klassenbibliothek enthält weitere Unterstützungen für parallele Programmierung mit Threads. Moderne JVMs bilden einen Java-Thread auf Betriebssystem-Threads ab und profitieren somit von Prozessoren mit multiplen Rechenkernen. Die Dynamik erreicht es durch den Aufbau. Vor allem durch die Dynamik bzw. der Anpassungsfähigkeit an sich ändernde Rahmenbedingungen anzupassen. Da die Module erst zur Laufzeit gelinkt werden, können beispielsweise Teile der Software (etwa Bibliotheken) neu ausgeliefert werden, ohne die restlichen Programmteile anpassen zu müssen. Man kann Interfaces als Basis für die Kommunikation zwischen zwei Modulen einsetzen, während sich die eigentliche Implementierung dynamisch und beispielsweise auch während der Laufzeit ändern kann.

Objektorientierung

Die Grundidee der objektorientierten Programmierung ist, Daten und zugehörige Funktionen möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln (Abstraktion). Die Absicht dahinter ist, große Softwareprojekte einfacher zu verwalten und die Qualität der Software zu erhöhen. Ein weiteres Ziel der Objektorientierung ist ein hoher Grad der Wiederverwendbarkeit von Softwaremodulen.

Ein neuer Aspekt von Java gegenüber beispielsweise der objektorientierten Programmiersprache C++ ist die explizite Unterscheidung zwischen Schnittstellen und Klassen, die man durch entsprechende Schlüsselwörter interface und class ausdrückt. Es unterstützt kein Erben von mehreren unabhängigen Basisklassen (sogenannte „Mehrfachvererbung“ wie in C++ oder Eiffel üblich), wohl aber das Implementieren einer beliebigen Zahl von Schnittstellen, womit sich viele der entsprechenden Probleme lösen lassen. Dabei kann man Methodensignaturen und Standardimplementierungen von Methoden an die abgeleiteten Klassen weitergeben, jedoch keine Attribute.

Es ist nicht vollständig objektorientiert, da die Grunddatentypen (int, boolean usw.) keine Objekte sind. Dies hängt mit der Syntax zusammen. Die Semantik, Grammatik und Syntax von Java sind in der Java Language Specification (Java-Sprachspezifikation) von Sun Microsystems dokumentiert. Das folgende Beispielprogramm gibt die unter Entwicklern bzw. Programmierern klassische Meldung „Hallo Welt!“, gefolgt von einem Zeilenumbruch, auf dem Ausgabemedium aus. Mittels Autoboxing kann man in die entsprechenden Objekttypen und umgekehrt umwandeln.

Reflexion

Reflexion (englisch reflection) bedeutet in der Programmierung, dass ein Programm die eigene Struktur kennt (englisch introspection) und/oder diese modifizieren kann (englisch intercession). Auch Java bietet eine Reflexion-API als Bestandteil der Laufzeitumgebung an. Damit ist es möglich, zur Laufzeit auf Klassen und Methoden zuzugreifen, deren Existenz oder genaue Ausprägung zur Zeit der Programmerstellung nicht bekannt war. Häufig wird diese Technik im Zusammenhang mit dem Entwurfsmuster Fabrikmethode (Factory Method) angewandt.

Annotationen

Annotationen erlauben die Notation von Metadaten und ermöglichen bis zu einem gewissen Grad benutzerdefinierte Spracherweiterungen. Sinn der Annotationen ist unter anderem die automatisierte Erzeugung von Code und anderen in der Software-Entwicklung wichtigen Dokumenten für wiederkehrende Muster anhand kurzer Hinweise im Quelltext. Früher hat man dafür ausschließlich Javadoc-Kommentare mit speziellen JavaDoc-Tags verwendet, deren Auswerung von Doclets wie zum Beispiel dem XDoclet stattgefunden hat.

Annotationen können auch in den kompilierten Class-Dateien enthalten sein. Für die Verwendung wird der Quelltext folglich nicht benötigt. Insbesondere sind die Annotationen auch über die Reflection-API zugänglich. Man kann sie beispielsweise zur Erweiterung des Bean-Konzeptes verwenden. Doch darüber schreibe ich in naher Zukunft einen gesonderten Beitrag.

Wo findet Java Einsatz?

Webanwendungen

Anwendungen, die man auf einem Webserver lädt, startet und die beim Benutzer in einem Webbrowser ablaufen bzw. dargestellt werden. Üblicherweise läuft ein Teil der Webanwendung auf dem Server (die Geschäftslogik und Persistenz) und ein anderer Teil im Webbrowser (die Logik der grafischen Benutzeroberfläche). Der Serverteil wird üblicherweise vollständig in Java geschrieben, der Browserteil üblicherweise in HTML und JavaScript. Es ist jedoch auch möglich, Java-Webanwendungen inklusive GUI-Logik vollständig in Java zu schreiben (siehe z. B. Google Web Toolkit oder die Remote Application Platform). Bekannte Beispiele für Java-Webanwendungen sind Twitter, Jira, Jenkins. Zwar nicht vollständig, aber Gmail ist zu großen Teilen auch damit geschrieben.

Desktop-Anwendungen

Unter Desktop-Anwendungen oder Applikationen fasst man normale Desktop-Programme zusammen. Sowohl Internet-Kommunikationsprogramme als auch Spiele und/oder Office-Anwendungen, die auf einem normalen PC laufen, haben diese Bezeichnung. Bekannte Beispiele für Java-Desktop-Anwendungen sind die integrierte Entwicklungsumgebung Eclipse oder das mittlerweile von Microsoft aufgekaufte Computerspiel Minecraft.

Applets

Java-Applets sind Anwendungen, die man normalerweise in einem Webbrowser ausführt. Sie sind üblicherweise auf einen durch ein spezielles HTML-Tag definierten Bereich einer Webseite beschränkt. Voraussetzung für die Ausführung der Applets ist ein Java-fähiger Browser. Eine Unterstützung dieser Anwendungsform liegt seit der Version 11 nicht mehr vor.

Apps

Apps sind kleinere Applikationen für mobile Endgeräte wie Handys, Smartphones, PDAs oder Tablets. Sie laufen üblicherweise auf speziellen, für die Ausführung von Java-Anwendungen optimierten Plattformen wie Java ME. Native Apps für das Android Betriebssystem von Google sind in der Regel auch damit programmiert, basieren aber auf einer abweichenden Klassenbibliotheks-API.

Entwicklungsumgebungen

Es gibt eine große Vielfalt von Entwicklungsumgebungen für Java, sowohl proprietäre als auch Open Source. Die meisten Entwicklungsumgebungen dafür sind selbst ebenfalls in Java geschrieben.

Die bekanntesten Open-Source-Umgebungen sind das von der Eclipse Foundation bereitgestellte Eclipse und das von Sun entwickelte NetBeans.

Unter den kommerziellen Entwicklungsumgebungen sind IntelliJ IDEA von JetBrains, siehe meinen Beitrag, JBuilder von Borland sowie JCreator und das auf NetBeans basierende Sun ONE Studio von Sun, am verbreitetsten. Außerdem gibt es noch eine Version von Eclipse, die von IBM unter dem Namen WebSphere Studio Application Developer („WSAD“) vertrieben wurde und ab Version 6.0 Rational Application Developer („RAD“) heißt. Auch in XCode von Apple lässt sich damit schreiben. Doch zu empfehlen ist es eher nicht, da es primär für C++ und C optimiert ist.

Sehr viele Texteditoren bieten Unterstützung dafür, darunter Emacs, jEdit, Atom (Ist aufgrund eines Hacks nicht mehr verfügbar 😉 ), Visual Studio Code, Vim und Notepad++, über die ich in zukünftigen Beiträgen schreibe.

Compiler

Ein Compiler übersetzt Java-Quellcode (Dateiendung „.java“) in einen ausführbaren Code. Grundsätzlich unterscheidet man zwischen Bytecode- und Nativecode-Compilern. Einige Laufzeitumgebungen verwenden einen JIT-Compiler, um zur Laufzeit den Bytecode häufig genutzter Programmteile in nativen Maschinencode zu übersetzen.

Bytecode Compiler

Im Normalfall übersetzt der Java-Compiler die Programme in einen nicht direkt ausführbaren Bytecode (Dateiendung „.class“), den die Java Runtime Environment (JRE) später ausführt. Die HotSpot-Technologie kompiliert den Bytecode zur Laufzeit in nativen Prozessorcode und optimiert diesen abhängig von der verwendeten Plattform. Diese Optimierung findet dabei nach und nach statt, sodass der Effekt auftritt, dass Programmteile nach mehrmaliger Abarbeitung schneller werden. Andererseits führt diese Technik, die ein Nachfolger der Just-in-time-Kompilierung ist, dazu, dass man mit Java-Bytecode, Anwendungen theoretisch genauso schnell wie nativ kompilierte Programme ausführen kann.

Native Compiler

Es existieren auch Compiler für Java, die Quelltexte oder den Bytecode in „normalen“ Maschinencode übersetzen können, sogenannte Ahead-of-time-Compiler. Nativ kompilierte Programme haben den Vorteil, keine JavaVM mehr zu benötigen aber auch den Nachteil, nicht mehr plattformunabhängig zu sein.

Beispiele für native Java Compiler waren Excelsior JET (eingestellt, bis Java SE 7), sowie GNU Compiler for Java (GCJ, eingestellt, bis J2SE 5.0) wie MinGW, Cygwin oder JavaNativeCompiler (JNC).

Wrapper

Als weitere Möglichkeit kann das Java-Programm in ein anderes Programm „eingepackt“ (englisch to wrap) werden. Unter anderem nennt man dies auch Adapter. Diese äußere Hülle dient dann als Ersatz für ein Java-Archiv. Sie sucht selbständig nach einer installierten Java-Laufzeitumgebung, um das eigentliche Programm zu starten und informiert den Benutzer darüber, wo er eine Laufzeitumgebung herunterladen kann, sofern noch keine installiert ist. Es ist also immer noch eine Laufzeitumgebung nötig, um das Programm starten zu können, aber der Anwender erhält eine verständliche Fehlermeldung, die ihm weiterhilft.

Java Web Start ist ein etwas eleganterer und standardisierter Ansatz für diese Lösung. Es ermöglicht die einfache Aktivierung von Anwendungen und garantiert, dass immer die neueste Version der Anwendung ausgeführt wird. Dadurch bleiben einem durch die Automatisierung komplizierte Installations- oder Aktualisierungsprozeduren erspart.

Beispiele für Java-Wrapper sind JSmooth oder Launch4J. JBuilder von Borland und NSIS sind ebenfalls in der Lage, einen Wrapper für Windows zu erstellen.

Fazit

Ein Fazit gibt es hierfür nicht, da ich es mir nicht anmaße, etwas zu beurteilen, dass ich noch nicht zu einem großen Teil verstehe. In diesem Zusammenhang vielleicht in den zukünftigen Beiträgen zu finden.

Der Beitrag Java – Endlose Möglichkeiten der Softwareentwicklung erschien zuerst auf CEOsBay.

Maven vereinfacht den Softwareerstellungsprozess, bietet ein einheitliches System für die Entwicklerarbeit, hochwertige Projektinformationen, Richtlinien für das Festlegen von Best Practices und erleichtert die Migration zu neuen Funktionen durch mehr Transparenz. Es beschreibt sowohl, wie Software gebaut wird, als auch deren Abhängigkeiten. Apache hilft sowohl bei der Verwaltung von Projekten und dient als Tool zum Verständnis. Es hilft also dabei, den Zustand eines Projekts zu organisieren und relativ schnell darzustellen.

Primär wird das Programm von Entwicklern und Projektmanagern bei Java-Anwendungsprojekten verwendet. Das Tool kann nützlich sein, um den Zustand eines Projektes auf einem Blick für technisch weniger versierte Personen, wie Führungspersönlichkeiten und Investoren, zusammenzufassen und gleichzeitig, um einige Prozesse bei der Softwareentwicklung zu automatisieren.

Maven basiert auf dem Objektmodell. Projekte werden als eine Pom.xml-Datei gespeichert. Das Tool verwaltet Projekt-Builds, Reportings und Dokumentationen aus einer zentralen XML-Informationsbasis. Mit der Standard-Plug-in-Architektur kann man es über den Standard-Input mit so gut wie jeder Anwendung nutzen und kollaborieren. Es vereinfacht den Prozess für das Erstellen von Java-Anwendungen erheblich, sodass der Nutzer den Status des Projektes viel einfacher einschätzen kann.

Der Name Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Kurze Zeitreise

Maven entstand in der Apache Software Foundation aus Frust über den Build-Prozess von Turbine. Es wurde bald zum Top-Level-Projekt aufgrund der Notwendigkeit, die Builds der vielen unterschiedlichen Projekte der Apache Software Foundation möglichst zu vereinheitlichen und somit auch zu vereinfachen.

Durch die vereinheitlichten Strukturen konnten Mitglieder unterschiedlicher Entwicklungsteams zwischen den einzelnen Teilprojekten wechseln und produktivere Arbeitsergebnisse erzielen. Dank der projektübergreifenden Standardisierung war es nicht mehr notwendig, sich in komplizierte Prozesse einzuarbeiten, um das Projekt ausführen und testen zu können.

Die Entwicklung von Maven 1 wurde im Jahr 2003 begonnen und am 13. Juli 2004 als Version 1.0 veröffentlicht. Die Umsetzung wurde jedoch sehr schnell realisiert, sodass einige Eigenheiten nicht bedacht wurden. Beispielsweise gab es Probleme bei der Performance sowie einen Überschuss an Konfigurationsdateien und -angaben, die es zu beherrschen galt. 2014 wurde das End of Life (EoL) von Maven 1 verkündet. Die letzte veröffentlichte Version ist 1.1 vom 25. Juni 2007.

Im Jahr 2005 wurde parallel damit begonnen, Maven 2 zu entwickeln, welches mit Version 2.0 am 19. Oktober 2005 fertiggestellt wurde. Mit dem Major-Release 2 wurde Maven von Grund auf überarbeitet und bekannte Probleme aus der Vorgängerversion wurden behoben. Aus diesem Grund sind Maven 1 und Maven 2 untereinander inkompatibel. Am 18. Februar 2014 wurde das End of Life von Maven 2 kommuniziert. Die letzte veröffentlichte Version ist 2.2.1 aus November 2009.

Die Entwicklung von Maven 3 begann im Jahr 2008, bei der man sich insbesondere auf die Kompatibilität zwischen Maven 2 und 3 konzentrierte.

In der zweiten Hälfte des Jahres 2021 wurden die Arbeiten an Maven 4 begonnen. Eine wesentliche Verbesserung ist die stark optimierte Unterstützung von Multi-Modul-Projekten.

Wie funktioniert Maven?

Maven benötigt zur Ausführung eine Java virtuelle Maschine (JVM) und ist aufgrund dieses Umstandes plattformunabhängig. Aus diesem Grund kann es auf jedem Betriebssystem ausgeführt werden, für das eine Java VM verfügbar ist.

Der Kern von Maven ist mit wenigen Megabyte als Paket kompakt gehalten. Die interne Struktur ist modular aufgebaut. Sämtliche Funktionen werden über Erweiterungen, sogenannte Plugins, bei der erstmaligen Verwendung über ein öffentliches im Internet verfügbares Repository, Maven Central genannt, nachgeladen und in einem lokalen Repository abgelegt.

Maven ist deklarativ und basiert auf zwei wesentlichen Paradigmen. Zum einen auf „Don’t Repeat Yourself“ (DRY bzw. Wiederhole dich nicht selbst) bedeutet sinngemäß im Kontext von Maven, dass man nicht bei jedem Projekt dieselben Build-Schritte neu definiert muss. Und auf „Convention over Configuration“ (CoC bzw. Konvention vor Konfiguration). Dies bezieht sich auf die Konfigurationsdatei (POM), mit denen Maven-Projekte beschrieben werden. Durch festgelegte Konventionen haben möglichst viele Konfigurationseinträge gemeingültige Vorbelegungen (Default-Werte), die für die meisten Anwendungsfälle bereits die erwünschten Ergebnisse produzieren.

Maven folgt den beiden beschriebenen Paradigmen über den gesamten Zyklus der Softwareerstellung konsequent. Eine wichtige Voraussetzung für eine erfolgreiche Automatisierung der einzelnen Schritte des Softwareerstellungsprozesses sind strikte Vereinheitlichungen, wie sie durch die beiden Paradigmen DRY und CoC geschaffen werden.

Obwohl Maven bereits sehr viele Vorgaben liefert, können Projekte diese Vorgaben an ihre tatsächlichen Bedürfnisse anpassen. Sowohl für künftige neuere Versionen von Maven als auch bei der Anbindung von Drittanbieterprodukten ist es eine bewährte Praxis, möglichst nahe am Maven-Standard zu bleiben.

Wichtige Begriffe bei der Arbeit mit Maven

Im Zusammenhang mit Maven werden wichtige Begriffe verwendet, mit denen man vertraut sein sollte, um effektiv damit zu arbeiten:

• Artifacts (Artefakte) Diese werden in Maven sowohl Plugins als auch Abhängigkeiten zu externen Programmbibliotheken und die selbst erstellten binären Programmdateien des eigenen Softwareprojektes bezeichnet.
• Lifecycles (Lebenszyklen) Dies kann auch als Workflow oder Prozess verstanden werden. Maven kennt drei Lifecycles: „clean“, „site“ und „build“.
• Phases (Phasen) In diesen werden die einzelnen Schritte innerhalb eines „Lifecycles“ bezeichnet, die in festgelegter linearer Reihenfolge durchlaufen werden. Der Build-Lifecycle Default kennt 23 Schritte.
• Goals (Ziele) Sind einzelne Aktionen bzw. Funktionalitäten, die in einem Plugin bereitgestellt werden.
• Archetypes (Archetypen) In diesen können Gerüste für unterschiedlichste Arten von Softwareprojekten erstellt werden, deren Struktur dem Standard von Maven entspricht. Was auch als ein wesentliches Merkmal von Maven-Projekten ist. Die einheitliche Verzeichnisstruktur, auf die ich nachfolgend eingehen werde.

Verzeichnisstruktur

my-project/ – Wurzelverzeichnis

pom.xml – Projektbeschreibung (Build-Logik)

src/ – alle Eingabedateien

main/ – Eingabedateien für die Erstellung des eigentlichen Produkts

java/ – Java-Quelltext-Dateien

resources/ – Projektdateien, die kein Java-Quellcode sind, aber für die Übersetzung oder zur Laufzeit benötigt werden, z. B. Bilder, SQL, Java-Properties-Dateien etc.

test/ – Eingabedateien, die für automatisierte Testläufe benötigt werden

java/ – Testfälle, die als Java-Quellcode vorliegen, z. B. JUnit-Testfälle

resources/ – Zusätzliche Ressourcen für Testfälle

target/ – Alle durch Maven während des Build-Vorgangs erstellten Dateien

classes/ – kompilierte Java-Klassen

Die Konfigurationsdatei „pom.xml“

Die Konfigurationsdatei für Maven-Projekte hat die offizielle Bezeichnung „Project Object Model (POM)“und ist als pom.xml im Wurzelverzeichnis des Projektes abgelegt. Im Kontext des Build-Managements ist die pom.xml die Build-Logik, die von externen Werkzeugen wie dem Automatisierungsserver Jenkins aufgerufen wird. Über Jenkins habe ich bereits geschrieben.

Die zwingenden Basisangaben für ein Projekt innerhalb einer POM sind die sogenannten GAV-Parameter, zuzüglich des Packagetyps. GAV steht für (G) = GroupID, (A) = ArtifactId und (V) = Version. Die GAV-Koordinaten müssen für jedes Projekt eindeutig sein und dürfen nicht mehrfach Verwendung finden.

Abhängigkeiten bzw. (Dependency Management)

Einer der wichtigsten Faktoren für den Erfolg von Maven ist der einfache Umgang mit fremden Abhängigkeiten, sogenannten 3rd Party Libraries. Externe Abhängigkeiten werden in der pom.xml notiert und über ihre GAV-Koordinaten eindeutig und transitiv aufgelöst. Die definierten Abhängigkeiten werden nicht physisch in die Versionsverwaltung mit aufgenommen, sondern während des Buildvorgangs im Projekt-Ausgabeverzeichnis target bereitgestellt.

Bei der Verwendung eines Artefaktes prüft Maven, ob es bereits lokal im Repository vorhanden ist. Das lokale Repository ist ein verstecktes Verzeichnis mit der Bezeichnung .m2/repository und findet sich im home-Verzeichnis des am Betriebssystem angemeldeten Nutzers.

Wird von Maven das angeforderte Artefakt im lokalen Repository nicht gefunden, wird in einem öffentlichen Remote-Repository danach gesucht. Bei erfolgreicher Suche wird das Artefakt im lokalen Repository verfügbar gemacht. Das Wichtigste öffentlich frei verfügbare Repository für Java-Artefakte lautet „Maven Central“ und wird von dem Unternehmen Sonatype betrieben.

Es besteht die Möglichkeit, einen eigenen Repository-Server zu betreiben, um selbst erstellte Artefakte im Unternehmen bzw. im Intranet für andere Projekte bereitzustellen oder diese über das Internet zur Verfügung zu stellen.

Wichtige Implementierungen zum Hosten eigener Artefakte sind Sonatype Nexus OSS oder JFrog Artifactory, für die es sowohl freie Community Versionen als auch kommerzielle Enterprise-Varianten gibt. Diese Lösungen können neben den verschiedenen Java-Artefakten auch andere Formate wie beispielsweise Docker Images, RubyGems, .NET nuget oder NPM verwalten. Maven Central, das größte Open-Source-Repository, wird mit Nexus OSS betrieben.

Maven-Lebenszyklen (Lifecycles)

Wie bereits vorher erwähnt, kommen in einem Maven Workflow verschiedene Lebenszyklen zum Einsatz. Diese sind:

• clean (Zum Löschen von Ergebnissen vorheriger Builds, mit den Phasen pre-clean, clean, post-cl
• build (default) (Zum Erstellen eines Projekts im Rahmen der verschiedenen Phasen
• site (Zum Erstellen von Webseiten zur Projektdokumentation und Reports, mit den Phasen pre-site, site, post-site, site-deploy.

Maven geht dabei jeweils von einem Zyklus aus, der bei der Softwareerstellung im Allgemeinen durchlaufen wird. Es muss aber nicht jedes Softwareprojekt alle Phasen des im Folgenden verkürzt dargestellten Default-Zyklus verwenden. Die Standardfunktionalität kann durch die Einbindung von zusätzlichen Plug-ins an die entsprechende Phase erweitert werden.

• validate bzw. validieren (Es wird überprüft, ob die pom.xml und die Projektstrukturen vollständig, valide und gültig sind.
• compile bzw. kompilieren (In dieser Phase wird der Quellcode kompiliert.
• test bzw. testen (Hier wird der kompilierte Code durch das eingebundene Unit-Test-Framework (z. B. JUnit, TestNG) getestet. Maven berücksichtigt dabei in späteren Zyklen, dass Testklassen normalerweise nicht in der auszuliefernden Software vorhanden sind.
• package bzw. verpacken (Das Kompilat wird – ggf. mit anderen nicht kompilierbaren Dateien – zur Weitergabe verpackt. Häufig handelt es sich dabei um eine JAR-Datei.
• integration-test bzw. Integrationstests (Bereitstellen der programmatisch erstellten Integrationstests mittels Behavior Driven Development (z. B. Cucumber, jGiven).
• verify bzw. Gültigkeitsprüfung des Softwarepakets (Überprüfung der Artefakte, ob die festgelegten Spezifikationen erfüllt wurden, D.H. die bereitgestellten Integrationstests werden ausgeführt.
• install bzw. das Kopieren in die lokale Maven-Repository (Kopiert das Softwarepaket ins lokale Maven-Repository, um es dann in anderen lokalen Maven-Projekten verwenden zu können. Dies ist insbesondere für modulare Projekte von Bedeutung.
• deploy bzw. anwenden (Lädt das Softwarepaket in ein entferntes Maven-Repository hoch, wonach es auch anderen Entwicklern global zur Verfügung steht.

Fazit

Hierbei kann man sich relativ kurzfassen. Ein Software-Projekt sollte stehts mit einem vernünftigen Buildmanagement ausgestattet sein. Das Open-Source-Tool bietet sich dabei vor allem bei Java-Projekten an, zumal es selbst auf Java basiert. Es ist ebenso möglich, Maven durch selbst entwickelte Plugins zu erweitern. Aufgrund dieser Eigenschaft wird es auch als Plugin Execution Framework bezeichnet. Man kann damit die Kollaboration bei der Entwicklung durch Programmierer und Projektmanager mit verschiedensten Skill-Sets wesentlich erleichtern bzw. vereinfachen.

Der Beitrag Apache Maven – Projekte inklusive Abhängigkeiten mühelos verwalten erschien zuerst auf CEOsBay.

Bei Solidity handelt es sich um die primäre Sprache auf Ethereum sowie auf anderen privaten Blockchains, wie der unternehmensorientierten Hyperledger Fabric Blockchain. SWIFT (The Society for Worldwide Interbank Financial Telecommunication) hat ein Proof of Concept mit Solidity auf Hyperledger Fabric implementiert.

Was ist SWIFT?

SWIFT ist eine Organisation, die ein besonders sicheres Telekommunikationsnetz (das SWIFTNet) betreibt. Mehr als 11.000 Banken weltweit nutzen das SWIFTNet. Darüber hinaus standardisiert SWIFT den Nachrichtenverkehr der Finanzinstitute untereinander und bietet Software sowie Services im Bereich der Finanztransaktionen an. SWIFT ist eine Genossenschaft im Besitz der Banken und ist dem EU-Recht unterworfen.

Die erste Spezifikation von Solidity erfolgte durch Gavin Wood im August 2014. Nachfolgend übernahm die Ethereum Foundation unter Leitung von Christian Reitwiessner die Weiterentwicklung. Solidity ist die vierte und am weitesten entwickelte Sprache, die man für die Ethereum Virtual Machine (EVM) entwickelt hat.

Beschaffenheit von Solidity

Wie anfangs angesprochen, basiert Solidity auf JavaScript. Sie ist in ihrer Beschaffenheit eine statische typisierte Programmiersprache. Entwickelt, um Smart Contracts für die Ethereum Virtual Machine (EVM) zu programmieren. Solidity-Contracts kann man in Bytecode kompilieren und von der EVM ausführen lassen. Gegebenenfalls lädt man dies dann über die Ethereum-Geth-Konsole in die Ethereum–Blockchain hoch.

Kompilierung von Solidity Code

Man kann den Code über verschiedene Wege kompilieren. Zum einen über den Online-Compiler, über den Kommandozeilen-Solidity-Compiler solc oder über den in die Ethereum-IDE Mix eingebauten Compiler.

Die Solidity-Syntax ist stark an die ECMAScript-Syntax angelehnt, um Webentwicklern den Einstieg in die Smart-Contract-Entwicklung zu erleichtern. Im Unterschied zu ECMAScript ist sie aber statisch typisiert und unterstützt variadische Rückgabewerte. Im Vergleich mit den zuvor bestehenden, vergleichbaren Sprachen (LLL, Serpent, Mutan) unterstützt Solidity komplexe Variablentypen wie hierarchische Mappings und Structs, die auch verschachtelt werden können, sowie die Vererbung für Contracts. Es wurde auch ein Application Binary Interface (ABI) spezifiziert, sodass Interaktionen externer Anwendungen und Bibliotheken wie beispielsweise Web3.js mit Ethereum-Contracts möglich sind. Solidity geriet mit dem Hack von „The DAO“ in die Schlagzeilen.

Was ist eine DAO?

Unter DAO versteht man eine Dezentralisierte Autonome Organisation. Die Steuerung dieser Organisation wird durch ein transparentes Computerprogramm bewerkstelligt. Das Programm wird weder von Aktionären gesteuert noch von einer zentralen Regierung beeinflusst. Die Aufzeichnung der Finanztransaktionen und die Programmregeln einer DAO werden auf einer Distributed-Ledger-Technologie (DLT) aufrechterhalten. Die erste DAO war übrigens Dash.

The Dao

The DAO ist die bekannteste DAO, die bislang in der Ethereum–Blockchain implementiert wurde. Die Firma Slock.it war für die Entwicklung und Veröffentlichung verantwortlich. Liest sich ja fast wie eine Anschuldigung. Grüße an Jeffrey Berns 😉 Grob zusammengefasst besteht die Aufgabe von The DAO darin, Ether durch Verkauf von Stimmberechtigungsanteilen einzunehmen, ein Entscheidungsgremium über die Verwendung gesammelter Ether abzuhalten und zu überweisen. Es handelt sich im Grunde genommen um eine autonome und automatisierte Investmentfirma. The DAO wurde im April 2016 in die Blockchain hochgeladen und durchlief ein Crowdfunding bis zum 28. Mai 2016. Zahlungsmittel war Ether. The-DAO-Token, die zur Stimmabgabe, für die in The DAO getroffenen Entscheidungen berechtigen, können immer noch auf diversen Kryptobörsen gehandelt werden.

Am 17. Juni 2016 machte ein Unbekannter durch einen Fehler im Smart Contract von The DAO 3,6 Millionen Ether unbrauchbar. Diese waren damals rund 65 Millionen Euro wert. Eine harte Abspaltung (englisch ‚hard fork‘), die den Angriff rückgängig macht, wurde mehrheitlich beschlossen. Durch diese harte Abspaltung wurde der angegriffenen DAO das gesamte Ether entzogen. Durch diesen Prozess entstanden zwei Blockchains, von denen die ursprüngliche als Ethereum Classic (ETC) weitergeführt wird. Die Ethereum Foundation hat anhand verschiedener Metriken und der Abstimmung der Community entschieden, ihre Entwicklungstätigkeit nur auf die abgespaltene (oder geforkte) Hauptblockchain (weiterhin Ethereum genannt) zu beschränken und sich nicht mehr mit Ethereum Classic zu beschäftigen.

Übrigens ist Uniswap, Thema vor 2 Tagen, ebenfalls in Solidity geschrieben 😉

Mir ist beim Schreiben aufgefallen, dass ich meinen Beitrag bzgl. Ethereum noch etwas ausarbeiten werde. Ich werde dies in den kommenden Tagen in Angriff nehmen 😉

So langsam wandelt sich dieses Vorhaben mit dem Blog zu einer lebenden und wachsenden Dokumentation.

Allen ein schönes und erholsames Wochenende!

Der Beitrag Solidity – Die Sprache für Smart Contracts auf der Ethereum-Blockchain erschien zuerst auf CEOsBay.