Hinweise zur Migration auf jadice web toolkit 7
Diese Anleitung gilt für jadice web toolkit Version 7 vom 17.04.2026.
Die Hinweise gelten für die Migration von jadice web toolkit 6 auf 7.
Eine Übersicht der Versionen des jadice web toolkit finden Sie hier.
In den meisten Fällen sollte es ausreichend sein, die Version 6 des jadice web toolkit in Ihrem dependency-management durch die aktuellste 7 zu ersetzen.
Benötigen Sie Hilfe bei der Migration auf Version 7? Nehmen Sie gerne Kontakt mit uns auf!
Inhalt
- 1 Inhalt
- 2 Neue Funktionen und Features
- 2.1 Spring Boot 4
- 2.2 GWT 2.13.0
- 2.3 Stamp-Support beim Export
- 3 Änderungen bei Dependencies
- 4 API-Änderungen und Umbenennungen von Klassen und Packages
- 5 Änderungen am Verhalten
- 6 Änderungen in der Modulstruktur / Integration via Maven
- 7 Entfernte Klassen und Funktionalitäten
Neue Funktionen und Features
Spring Boot 4
Mit der Version 5.14 des jadice web toolkit wurde Spring Boot von Version 3.5 auf 4 geupdated. Beachten Sie hierzu auch den Spring Boot Migration Guide.
Besonders erwähnenswert in diesem Zuge ist, dass ein Servlet 6.1 App-Server erforderlich ist, wenn Sie Traditional Deployment (Bau einer WAR-Datei und nicht Runnable-JAR) verwenden.
GWT 2.13.0
Mit der Version 5.14 des jadice web toolkit wurde GWT auf Version 2.13.0 angehoben. Die Release-Notes hierzu finden Sie hier.
Stamp-Support beim Export
Beim Export von Dokumenten lassen sich nun “Stempel” anbringen. Der Stempel-Text kann konfigurativ fest eingestellt werden, oder beim Aufruf des ExportOperationMessageListener mitgegeben werden. Der Stempel-Text wird dann oben rechts auf dem Dokument auf jeder Seite eingebrannt.
webtoolkit:
exportConfiguration:
stampFontSize: 24
stampFontName: sans-serif
stampText: "Dieses Dokument ist eine Kopie"Änderungen bei Dependencies
Wenn Sie die BOM des jadice web toolkit verwenden, müssen Sie nichts weiter tun!
API-Änderungen und Umbenennungen von Klassen und Packages
Keine
Änderungen am Verhalten
Device-Pixel-Ratio
Auf hochauflösenden Displays (HiDPI/Retina) meldet der Browser einen window.devicePixelRatio größer als 1 — typischerweise 2 auf Retina-Displays. Das bedeutet: Ein CSS-Pixel entspricht physisch 2×2 Gerätepixeln.
Bisher wurden Dokumentseiten immer in der CSS-Pixelgröße des Anzeigebereichs gerendert. Auf einem HiDPI-Display skaliert der Browser das Bild dann intern hoch, um die physischen Pixel zu füllen — das Ergebnis ist ein sichtbar unscharfes Bild.
Mit der neuen Implementierung wird die Rendergröße mit dem devicePixelRatio multipliziert. Das erzeugte Bild enthält damit genug Pixel, um das Display nativ zu befüllen, und wird per CSS auf die ursprüngliche CSS-Größe zurückgesetzt. Das Ergebnis ist eine gestochen scharfe Darstellung auf HiDPI-Displays, ohne dass sich die wahrnehmbare Größe des Dokuments ändert.
Zusätzlich kann der Wert über ClientConfigurationManager.getClientConfiguration().setFixedDevicePixelRatio(1f); bei Bedarf manuell überschrieben werden — etwa um die Renderlast zu reduzieren oder eine konsistente Ausgabe in Testumgebungen sicherzustellen.
In früheren Implementierungen konnte das Verhalten über ClientConfigurationManager.getClientConfiguration().setQualityEnhancement(VALUE); gesteuert.
| Altes Verhalten | Neues Verhalten |
|---|---|---|
Default | Immer Device-Pixel-Ratio | Device-Pixel-Ratio entspricht dem vom Browser gelieferten Wert passend zum aktuellen Bildschirm und Browser-Zoom |
| Device-Pixel-Ratio entspricht dem vom Browser gelieferten Wert passend zum aktuellen Bildschirm und Browser-Zoom ( | - |
| - | Immer Device-Pixel-Ratio |
Tile-Compression-Type
Der neue Standard ist nun "PNGJ_BEST_SPEED".
Um die Einstellung zu ändern:
In der application.yml folgendes einstellen:
webtoolkit: tile-compression-type: IMAGEIO
alternativ programmatisch
ConfigurationManager.getServerConfiguration().setTileCompressionType(ServerConfiguration.TileCompressionType.IMAGEIO); Weitere Informationen: Tile-images file-formats
Änderungen in der Modulstruktur / Integration via Maven
Keine
Entfernte Klassen und Funktionalitäten
SetSaveAnnotationsHandlers
Ein manuelles Registrieren von einem SaveAnnotationsHanlder über die ServerConfiguration wird nun nicht mehr unterstützt. Die Registrierung erfolgt automatisch, wenn eine solche Implementierung mit @Component annotiert ist.