Core API revision

Java 8 basierend

Die gesamte Codebasis wird seit 5.0 auf Java 8 umgestellt. Dieses wurde nun weiter vorangetrieben. Teilweise jetzt erst wirklich auf Java 8 umgestellt.

Java 8 API Typen

Rückgabetypen wurden Stream, Duration, Instant, Executable und so weiter eingeführt.

Interfaces mit Defaultmethoden

Interfaces nutzen nun Default Methoden, um neue Funktionen bereitzustellen ohne dabei die Rückwärtskompatabilität zu brechen.

Nullability

In der gesamten Codebasis werden alle Methoden mit @NonNull oder @Nullable deklariert. Dadurch können die IDEs wie Eclipse und IntelliJ die Interaktion mit dem Spring Framework validieren. Viele der vorhandenen Null Checks konnten somit in dem Spring Framework entfernt werden.

Eigene APIs die auf Spring Framework Rückgabewerten basieren sollten nun auch von den Annotationen Gebrauch machen und somit im allgemeinen den Code von weiteren Null Checks befreien.

Performance Tuning

Component Scanning

Das Scannen des gesammten Classpath beim Programmstart kann viel Zeit in Anspruch nehmen. Dabei werden alle Klassen nach der Annotation @ComponentScan durchsucht. Im allgemeinen wird man die Startupzeit durch Angabe eines base packages verkürzen, da nicht mehr alle Klassen durchsucht werden müssen. Alternativ kann ein Scanning auch komplett verhindert werden, in dem man alle Komponentenklassen aufzählt.

Seit Spring Framework 5 kann man einen Annotationsprozessor zur Kompilierzeit verwenden (spring-context-indexer). Dieser erstellt eine META-INF/spring.components per JAR. Diese wird automatisch zur Laufzeit ausgewertet.

Component Model

Am effizientesten werden Komponenten in einer reinen Funktionalen Methode registriert. Dadurch entfällt das Component Scanning und es wird auch kein Reflection für die Factory Methoden verwendet. Ferner werden auch keine Annotationśkonfigurationen (Annotationpostprocessor) verwendet.

ProxyBeanMethods

Mit @Configuration(proxyBeanMethos=false) kann nun verhindert werden dass zur Laufzeit CGLIB Subklassen erzeugt werden. Dieses wird für die Imageerstellung mit der GraalVM benötigt.

Nachteil: Kein Abfangen von Cross @Bean Calls mehr möglich!

3rd Party Libs

Spring Boot Data unterstützen spring.data.jpa.repositories.bootstrap-mode=deferred. Damit werden der ORM Hibernate lazy initialisiert. Das ist ein nicht unerheblicher Anteil der Startupzeit einer Spring Anwendung. Die Initialisierung wird nun bei dem Ersten Zugriff durchgeführt.

Hibernate wurde auf 5.4.5 aktualisiert, welches interne Performance Steigerungen und weniger Speicherverbrauch zur Folge hat. Desweiteren wurde der Umgang mit Bytecode verbessert (Voraussetzung für lazy loading).

Jackson wurde auf mindesten 2.9.7 angehoben. Auch hier wurde die Startupzeit sowie die Responsezeit beim parsen von JSON verbessert.

Nur durch die Anhebung des Spring / Spring Boot Frameworks lassen sich Performancesteigerungen also erzielen.

GraalVM

Die Verwendung der GraalVM ist bereits seit Spring Framework 5.1 in Vorbereitung. Es werden unnötige interne Reflection vermieden. Nun ist in der Zwischenzeit set Spring Framework 5.1 das 19 GA von GraalVM erschienen. Spring Framework 5.2 kann mit native Image verwendet werden, aber es müssen die explizite Reflection Konfiguration und benötigte Kommandozeilenparameter angegeben werden damit ein Image erzeugt werden kann. Ziel der Entwicklung für Spring Framework 5.3 ist ein automatisches Setup (ootb) der Reflection Einstellungen durch eine Custom Graal Konfiguration zu ermöglichen.