Kurze Zeitreise

Die Geschichte von C# beginnt im Jahr 1999. Als Microsoft-Entwickler Anders Hejlsberg und sein Team an einer neuen Programmiersprache namens „Cool“ (kurz für „C-like Object Oriented Language“) arbeiteten. Das Projekt, Teil von Microsofts größerer .NET-Initiative, eine einheitliche Plattform für die Entwicklung von Webdiensten, Desktop-Anwendungen und verteilter Systeme zu schaffen. Cool sollte leistungsstark und einfach zu erlernen sein. Die Elemente von C, C++, Java und Delphi in einer Programmiersprache vereint.

Die ersten Schritte (2000-2002)

Im Juni 2000 kam die offizielle Vorstellung von Microsoft C#. Es war von Anfang an eng mit dem .NET-Framework verknüpft. Die Veröffentlichung der ersten Version von C# und dem .NET-Framework (Version 1.0) folgte im Jahr 2002. Sie bot grundlegende Funktionen für objektorientierte Programmierung, wie Klassen, Objekte, Vererbung und Polymorphismus. Auch wenn diese Version noch nicht über einige der leistungsfähigen Funktionen verfügte, die man in späteren Versionen hinzugefügte. War es dennoch eine attraktive Option für Entwickler, die eine Alternative zu Java oder C++ suchten.

Weiterentwicklung und Verbesserungen (2002-2010)

In den folgenden Jahren entwickelte sich C# kontinuierlich weiter, zahlreiche neue Funktionen und Verbesserungen kamen nach und nach hinzu. C# 2.0, dessen Veröffentlichung im Jahr 2005 stattfand, führte Generics, partielle Klassen, anonyme Methoden und Nullable-Werttypen ein. Diese Verbesserungen erleichterten die Programmierung und erweiterten die Möglichkeiten von C# erheblich.

C# 3.0 dann im Jahr 2007. Es brachte eine der bahnbrechendsten Neuerungen der Sprache: Language Integrated Query (LINQ) ins Spiel. LINQ ist eine Sammlung von Funktionen, die es ermöglichen, Daten aus verschiedenen Quellen (wie SQL-Datenbanken, XML-Dokumenten und in-memory Kollektionen) zu verarbeiten. Direkt in C#, und außerdem, zu manipulieren. Diese Version führte auch anonyme Typen, Erweiterungsmethoden und Lambda-Ausdrücke ein, was die Sprache noch flexibler und ausdrucksstärker machte.

Mit C# 4.0, das 2010 erschien, kamen einige wichtige Funktionen hinzu. Diese verbesserten die Interoperabilität von C# mit anderen Technologien und Programmiersprachen. Dazu gehörten dynamische Typen, benannte und optionale Parameter sowie verbesserte COM-Interoperabilität.

Aktuelle Entwicklungen (2010-heute)

C# 5.0, im Jahr 2012. Es fokussierte sich hauptsächlich auf die Verbesserung der asynchronen Programmierung durch die Einführung von Async und Await Keywords. Diese Funktionen ermöglichen es Entwicklern, heute noch, asynchronen Code auf einfache und saubere Weise zu schreiben. So kann man Anwendungen erstellen, die dadurch heute schneller und reaktionsfähiger sind.

Seitdem kamen weitere Versionen von C#, die jeweils neue Funktionen und Verbesserungen enthielten. C# 6.0 (2015) brachte einige Syntaktische Vereinfachungen wie Auto-Property-Initialisierer, Expression-bodied-Mitglieder, Nullbedingungsoperator (?.) und String-Interpolation.

Gefolgt von C# 7.0 (2017). Es kamen Tuples, Pattern Matching, lokale Funktionen und erweiterte Möglichkeiten für das Arbeiten mit Werttypen durch die Einführung von ref locals und ref returns mit rein.

Und C# 8.0 (2019) legte einen Schwerpunkt auf die Verbesserung von Sicherheit und Produktivität, indem es Funktionen wie Nullable Reference Types, Asynchronous Streams, Pattern Matching Enhancements, Indices und Ranges sowie Default Interface Members einführte.

Zuletzt C# 9.0 im Jahr 2020, dass sich auf die Verbesserung von Programmiersprachfunktionen konzentrierte. Dadurch konnte man den Umgang mit Daten und den Ausdruck von Algorithmen vereinfachen. Dazu gehörten beispielsweise Init-only-Properties, Records, Pattern Matching Enhancements, Top-Level-Statements und Target-typed New Expressions.

Parallel zur Entwicklung von C# hat Microsoft auch an der .NET-Plattform gearbeitet. Im Jahr 2016 veröffentlichte das Unternehmen .NET Core, eine plattformübergreifende, modulare und leichte Version von .NET, die für moderne Web- und Cloud-Anwendungen optimiert ist. Seit der Veröffentlichung von .NET 5 im Jahr 2020 hat Microsoft die traditionellen .NET-Frameworks und .NET Core vereint und setzt nun auf eine einzige .NET-Laufzeit und -Plattform.

Vorteile von C#

• Vielseitigkeit: Es eignet sich für eine breite Palette von Anwendungen und Projekten. Es wird häufig für die Entwicklung von Webanwendungen, Windows-Anwendungen, Cloud-basierten Diensten, Spielen, mobilen Anwendungen und sogar KI-Projekten verwendet.
• Objektorientierung: Es ist eine vollständig objektorientierte Sprache, was bedeutet, dass sie auf dem Prinzip der Kapselung von Daten und Verhalten innerhalb von Objekten basiert. Dies ermöglicht eine saubere Trennung von Anliegen und fördert Wiederverwendbarkeit und Erweiterbarkeit des Codes.
• Einfache und klare Syntax: Die Syntax von C# ist einfach und leicht verständlich, wodurch Programmierer schneller lernen und produktiver sein können. Die Sprache ist weniger fehleranfällig und erlaubt Entwicklern, effizienter und mit weniger Fehlern zu arbeiten.
• Leistungsstarke Entwicklungsumgebungen: C# wird von einer Vielzahl von Entwicklungsumgebungen unterstützt, insbesondere von Visual Studio Code, einer leistungsstarken integrierten Entwicklungsumgebung (IDE) von Microsoft. Dies ermöglicht Programmierern, schnell und effizient zu arbeiten, Code zu schreiben, zu testen und zu debuggen.
• Unterstützung und Gemeinschaft: Da C# von Microsoft entwickelt und unterstützt wird, profitiert die Sprache von einer starken Gemeinschaft und einer breiten Palette von Ressourcen, einschließlich Online-Tutorials, Dokumentationen und Foren. Die C#-Community ist bekannt für ihre Hilfsbereitschaft und ihr Engagement, neue Programmierer willkommen zu heißen und bei Problemen zu unterstützen.
• Interoperabilität: C# bietet eine hervorragende Interoperabilität mit anderen .NET-Sprachen und -Technologien. Durch die Nutzung der .NET-Bibliotheken und –Frameworks können Entwickler eine Vielzahl von Funktionalitäten in ihren Anwendungen leicht implementieren und erweitern.
• Skalierbarkeit und Leistung: C#-Anwendungen sind für ihre Leistung und Skalierbarkeit bekannt. Durch die Verwendung des Just-In-Time (JIT)-Compilers und anderer Optimierungstechniken bietet C# schnelle Ausführungszeiten und geringe Latenzzeiten, was für Anwendungen mit hohen Anforderungen an Geschwindigkeit und Reaktionsfähigkeit unerlässlich ist.
• Plattformübergreifende Entwicklung: Mit der Einführung von .NET Core und Xamarin ermöglicht C# die plattformübergreifende Entwicklung von Anwendungen für Windows, MacOS, Linux, iOS und Android. Dies eröffnet Entwicklern eine Vielzahl neuer Möglichkeiten und macht die Sprache noch attraktiver für Unternehmen und Entwickler.

Nachteile von C#

Obwohl es eine leistungsstarke und vielseitige Programmiersprache ist, gibt es einige Nachteile, die man beachten sollte, bevor man sich für diese Sprache entscheidet. Hier sind einige der wichtigsten:

• Leistung: Trotz der Verbesserungen in der Laufzeitumgebung und den Optimierungstechniken von .NET ist die Leistung von C#-Anwendungen möglicherweise nicht so gut wie die von Anwendungen, die in niedrigeren Programmiersprachen wie C oder C++ geschrieben sind. Die Verwendung von Just-In-Time (JIT)-Kompilierung und Garbage Collection kann zu einem gewissen Laufzeit-Overhead führen.
• Plattformabhängigkeit: Historisch gesehen war C# stark an das Windows-Ökosystem und die .NET-Plattform gebunden. Obwohl die Einführung von .NET Core und Xamarin die plattformübergreifende Entwicklung ermöglicht hat, ist die Unterstützung und Integration von C# in Nicht-Windows-Umgebungen möglicherweise nicht so nahtlos wie bei einigen anderen Programmiersprachen, insbesondere Java. Mir ist dies besonders aufgefallen, als ich zeitgleich für Android und iOS Devices kompiliert habe. Man muss einige Dinge beachten und Drittanbieter-Software installieren, um überhaupt vom Fleck zu kommen.
• Lernkurve: Obwohl es im Vergleich zu einigen anderen Programmiersprachen relativ einfach zu erlernen ist, kann es dennoch eine gewisse Zeit dauern, sich mit allen Funktionen und Konzepten der Sprache vertraut zu machen, insbesondere wenn man noch keine Erfahrung mit objektorientierter Programmierung hat.
• Größe des Ökosystems: Während das .NET-Ökosystem umfangreich ist und viele Bibliotheken und Frameworks bietet, kann es sein, dass bestimmte Drittanbieter-Bibliotheken oder -Tools nicht verfügbar sind oder nicht so umfangreich wie in einigen anderen Programmiersprachen.
• Proprietäre Natur: C# von Microsoft ist eine proprietäre Sprache. Obwohl es Open-Source-Implementierungen gibt (z.B. .NET Core und Xamarin), hängt die Entwicklung der Sprache und der zugehörigen Tools stark von Microsofts Strategie und Vision ab. Einige Entwickler ziehen es vor, sich auf Open-Source-Programmiersprachen wie Python oder Java zu konzentrieren, die nicht ein einzelnes Unternehmen kontrolliert.

Anwendungsbeispiele für C#

• Webanwendungen: Es ist eine beliebte Wahl für die Entwicklung von Webanwendungen, insbesondere mit dem ASP.NET-Framework. ASP.NET Core ist ein Open-Source-Webframework, das auf .NET Core basiert und die Entwicklung von modernen, leistungsstarken Webanwendungen ermöglicht.
• Windows-Anwendungen: Es eignet sich hervorragend für die Entwicklung von Windows-Desktop-Anwendungen. Mit dem Windows Presentation Foundation (WPF) Framework können Entwickler ansprechende Benutzeroberflächen und robuste Anwendungen erstellen.
• Mobile Anwendungen: Mit Hilfe von Xamarin, einer plattformübergreifenden App-Entwicklungsumgebung, können Entwickler C# verwenden, um native Anwendungen für iOS, Android und Windows Mobile zu erstellen.
• Spieleentwicklung: Die Unity-Engine, eine der weltweit führenden Spieleentwicklungsplattformen, unterstützt C# als Skriptsprache. Dies ermöglicht es Entwicklern, anspruchsvolle und leistungsfähige Spiele für verschiedene Plattformen zu entwickeln.

Fazit:

C# hat sich seit seiner Einführung zu einer der bevorzugten Programmiersprachen für Entwickler und Unternehmen entwickelt. Mit seiner Vielseitigkeit, leistungsstarken Entwicklungsumgebungen, der starken Unterstützung durch Microsoft und einer engagierten Community bietet C# eine hervorragende Grundlage für die Entwicklung einer Vielzahl von Anwendungen. Wenn man in Betracht zieht, eine neue Programmiersprache zu erlernen oder ein neues Projekt zu starten, sollte man auf jeden Fall die vielen Vorteile von C# in Betracht ziehen.

Der Beitrag C# – Als Brücke zwischen Innovation und Benutzererfahrung erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software 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.

Ab wann werden Frameworks relevant?

In der Regel definiert man als Programmierer oder als Team, zu Beginn eines Projekts, auf Basis der Anforderungen und der wirtschaftlichen Aspekte, die Herangehensweise.

Man hat immer die Auswahl, alles von Grund auf selber bzw. nativ zu programmieren, was zwar eine extrem individuelle Lösung darstellt und alles bis auf das kleinste Detail erstellt bzw. programmiert werden kann, ein CMS (Content Management System = Eine Software zur gemeinschaftlichen Erstellung, Bearbeitung, Organisation und Darstellung digitaler Inhalte zumeist zur Verwendung in Webseiten aber auch in anderen Medienformen) zu nutzen – Wobei ich Zweites in einem separaten Beitrag ausführlich thematisieren möchte (Übrigens basiert diese Webseite auch auf einem CMS. In diesem Fall handelt es sich um eine WordPress-Instanz). Und dann gibt es natürlich Frameworks. Wobei die Anforderungen an die Professionalität des Entwicklers bei dieser Herangehensweise relativ hoch angesiedelt sind. Allerdings muss man sagen, dass das hohe Maß an Flexibilität und die Verfügbarkeit ausgefeilter Struktur-Merkmale nicht unwesentlich sind.

Welche Frameworks gibt es?

Application Frameworks: Als Grundgerüst für die Programmierung von Anwendungen mit spezifischen Strukturen und Funktionen.

Web-Frameworks: Für die Entwicklung und Programmierung dynamischer Web-Sites und Web-Anwendungen.

Komponenten-Frameworks: Als Umgebungsrahmen für die Programmierung und Einbindung von Programm-Paketen.

Domain Frameworks: Als Rahmen für vordefinierte Problembereiche.

Coordination Frameworks: Zur Einrichtung von Geräte-Interaktionen bzw. für die Abfolge zu steuernder Einzelschritte.

Class Frameworks: Zur Zusammenfassung von „Klassen“ und „Methoden“, im Sinne einer optimalen Unterstützung des Programmierers bei der Implementierung seiner spezifischen Anwendungen.

Test Frameworks: Für das Testen von Programmen. Klassische Beispiele hierfür sind „Selenium“ für den Test von Webanwendungen und „JUnit“ für den Test von Modulen. Selenium habe ich in diesem Beitrag thematisiert.

Fazit

Eines der Vorteile ist, wie bereits erwähnt, dass Wiederkehrende Aufgaben schneller abgewickelt werden können, da im Framework bereits eine Reihe an Elementen vorprogrammiert sind. Diese können beliebig oft verwendet werden. Darüberhinaus beinhalteten Frameworks Basis-Bausteine, die auf die Design-Struktur eines Programms Einfluss nehmen. Sie bieten sich in der Regel bei speziellen Anforderungen und individuellen Lösungen an, so kann das vom Framework zur Verfügung gestellte Programmier-Gerüst eine gute Wahl darstellen. Nichtsdestotrotz sollte man meines Erachtens nach bei „kleineren“ Projekten die Nutzung von Content Management Systemen in Erwägung ziehen. Schlussendlich, hängt die Wahl der jeweiligen Herangehensweise und die Effizienz, in der das Projekt realisiert wird, häufig von der Qualifikation und dem Skillset eines jeden Programmierers ab.

Der Beitrag Frameworks – Effiziente Entwicklung und eine höhere Qualität durch Rahmenwerke erschien zuerst auf CEOsBay.