Während der letzten Jahre konnte man immer mal wieder über den Aufstieg der Java Enterprise Edition und dem Fall von Spring lesen (Spring is the new legacy), nur im richtigen Arbeitsleben sehe ich das bisher nicht. Seit über zehn Jahren arbeite ich in Langzeit-Projekten bei Firmen, die man als Enterprise bezeichnen kann, hauptsächlich Versicherungen und Banken, und die meiste Zeit davon habe ich Bibliotheken und Frameworks gebaut, die andere Entwickler dann nutzen, um ihren Businesscode zu implementieren. Für diese Art von Frameworks und Bibliotheken ist Spring meiner Meinung nach immer noch die beste Wahl, das dachte ich schon, bevor Spring 4 und Spring Boot herauskamen, aber jetzt bin ich noch überzeugter davon. In diesem Post schreibe ich über fünf Features, die ich in JEE vermisse.
- JavaConfig
- Property-Management und Environment
- Profile
- Auto-Configuration
- @Conditional Annotationen
JavaConfig
Im Kontext von Firmen-Frameworks und Bibliotheken bevorzuge ich definitiv eine zentrale Konfiguration. Für den Nutzer der Bibliothek ist viel leichter nachzuvollziehen, was passiert, wenn er sie verwendet. Autowiring und Component Scanning Magie via @Named, @Inject und Co. mag für die Anwendung des Entwicklers gut sein – für eine Bibliothek, die der Entwickler nicht zu 100% kennen kann, ist es das nicht. Und wenn man schon bei einer zentralen Konfiguration ist, geht nichts über JavaConfig, die in jeder IDE leicht gefunden werden kann, auch wenn sie nur in einem Jar im Klassenpfad ist, die ein schönes JavaDoc haben kann und so weiter. Ich habe schon früher über die Vorteile von JavaConfig geschrieben .
Property-Management und Environment
Spring war schon immer stark im Umgang mit Properties, Properties-Files zu importieren und diese in Konfigurationen zu verwenden war schon immer einfach. Seit der Einführung des Environments in Spring 3.1 ist es nun ein ziemlich komplettes Konzept, mit PropertySources, die Properties aus allen möglichen Quellen lesen können, nicht nur Dateien, einfach erweiterbar durch das Schreiben eigener PropertySources, und mit einem konsistenten Zugriff auf diese im Environment verfügbaren Properties in Konfigurationsdateien. Default Properties und das Überschreiben von Properties werden ebenfalls gut abgedeckt.
Profile
Wenn man eine Bibliothek oder ein Framework schreibt, ist es meistens der Fall, dass sie unter unterschiedlichen Bedingungen verwendet wird. Das mögen unterschiedliche Use-Cases sein, die eine leicht unterschiedliche Implementierung erfordern, das mögen unterschiedliche Laufzeitumgebungen sein etc. Mit den Profilen ist es einfach, unterschiedliche Konfigurationen zu definieren, die nur aktiv werden, wenn sie benötigt werden.
Auto-Configuration
Dieser Punkt ist neu und stammt von Spring Boot, einem jungen Projekt aus dem Spring-Ökosystem, das dabei hilft, Spring-Anwendungen auf Convention-over-Configuration-Art zu entwickeln. Er ist auch in Enterprise-Umgebungen extrem nützlich. Als Bibliothek- / Framework-Entwickler kann man in einer spring.factories – Datei im Klassenpfad unter META-INF auf eine Konfigurationsklasse verweisen. Wenn der Nutzer der Bibliothek die @EnableAutoConfiguration – Annotation verwendet, wird die Konfiguration automatisch zum ApplicationContext hinzugefügt. Auf diese Weise kann der Framework-Entwickler die für seine Bibliothek benötigte Konfiguration aufsetzen, ohne dass der Nutzer etwas tun muss.
Man kann argumentieren, dass das so ähnlich ist wie JEE-Annotationen in Business-Klassen zu haben und die Bibliothek zu scannen, aber das ist es nicht. Es ist immer noch eine zentrale Konfiguration, was in Enterprise-Umgebungen viel passender ist, und man kann eine Menge mehr damit machen, wie die Spring Boot – Leute zeigen (beispielsweise einen embedded Tomcat zu starten).
@Conditional Annotationen
Als Framework-Entwickler kann man mit diesen neuen Annotationen aus Spring 4 und Spring Boot viel Spaß haben. Man kann bestimmte Konfigurationsklassen nur unter bestimmten Bedingungen dem ApplicationContext hinzufügen, hier ist eine unvollständige Liste dieser Annotationen: @ConditionalOnBean, @ConditionalOnClass, @ConditionalOnExpression, @ConditionalOnMissingBean, @ConditionalOnMissingClass, @ConditionalOnResource, @ConditionalOnWebApplication und so weiter. Wie man sieht, kann man Konfigurationen abhängig vom Klassenpfad hinzufügen, man kann eine Konfiguration nur dann hinzufügen, wenn der Nutzer eine Bean eines bestimmten Typs erzeugt hat, man kann eine Konfiguration hinzufügen, wenn der Nutzer keine eigene desselben Typs erzeugt hat und vieles mehr. Es ist ein umfangreicher Werkzeugkasten für Bibliothek- / Framework-Entwickler.
Fazit
Ich kenne JEE nicht so gut, wie ich Spring kenne, also wenn es Vorschläge gibt, wie man obige Funktionalität in JEE erreichen kann: ich freue mich auf Kommentare! Ich lerne immer gerne dazu. Aber bezüglich des Wissens, das ich aktuell habe, bleibt mein Favorit für Bibliotheken und Firmen-Frameworks das Spring-Framework.
Und wenn Sie wissen wollen, wie wir die obige Funktionalität nutzen, um einen konfigurierbaren, erweiterbaren und leicht zu benutzenden Batch-Server mit viel Default-Funktionalität zu bauen, werfen Sie doch mal einen Blick auf spring-boot-starter-batch-web .
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.