Für die Anzeige von Webinhalten in einer SWT-Anwendung stehen in der Regel zwei Optionen zur Verfügung: das eingebaute Browser-Widget oder eine kommerzielle Lösung wie JxBrowser.

Dieser Artikel beleuchtet die Unterschiede zwischen beiden Ansätzen und unterstützt bei der Auswahl der passenden Lösung.

Die Migration zu JxBrowser ist unkompliziert. Der detaillierte Migrationsleitfaden deckt die gesamte API des SWT-Browsers ab.

Kurz und knapp 

SWT Browser JxBrowser
LizenzOpen SourceKommerziell
API Coverage8 Interfaces,
11 Klassen
373 Interfaces,
126 Klasses
Web-EngineUnterschiedlich; wird vom Betriebssystem bereitgestelltChromium 138
Unterstützte UI-ToolkitsSWTSWT, Swing, JavaFX, Compose Desktop
ProgrammiersprachenJavaJava, Kotlin
KundensupportNeinJa, vertraulich, mit SLA

Das eingebaute Browser-Widget ist einfach, aber funktional. Es nutzt die Webengine des jeweiligen Betriebssystems. Browser ist geeignet, wenn:

  • ausschließlich freie Software verwendet werden soll,
  • der Use Case einfach und unkritisch ist.

JxBrowser ist eine fortgeschrittene kommerzielle WebView-Komponente auf Basis von Chromium. Diese Option eignet sich, wenn:

  • der Use-Case komplex oder kritisch ist,
  • Kontrolle über die Browser-Engine-Version erforderlich ist,
  • eine konsistente Engine über alle Plattformen hinweg benötigt wird,
  • Webinhalte automatisiert getestet werden sollen,
  • erweiterte Funktionen erforderlich sind,
  • Support, Fehlerbehebungen oder individuelle Anpassungen notwendig sind.

Embedding 

Da der Browser Teil von SWT ist, lässt er sich sehr einfach einbetten:

var browser = new Browser(shell, SWT.NONE);
browser.setUrl("https://example.com");

Bei JxBrowser müssen zunächst die Abhängigkeiten ins Projekt integriert werden. Je nach Buildsystem können Maven-Artefakte verwendet, die JAR-Dateien direkt eingebunden oder ein Standalone-Eclipse-Plugin erstellt werden.

Nach dem Einbinden sieht der Code so aus:

var engine = Engine.newInstance(HARDWARE_ACCELERATED);
var browser = engine.newBrowser();
var browserView = BrowserView.newInstance(shell, browser);
browser.navigation().loadUrl("https://example.com");

Browser-Engines 

Die Grundidee hinter dem Standard Widget Toolkit (SWT) ist es, ein natives Look & Feel zu liefern. Deshalb nutzt SWT keine eigenen Komponenten, sondern die nativen Widgets des Betriebssystems.

Jedes SWT-Widget ist somit ein Wrapper um ein natives Gegenstück. Die API kommt von SWT, das Rendering, Accessibility, Fokusverwaltung usw. übernimmt das Betriebssystem. Auch der Browser funktioniert so.

Das Widget ist ein dünner Wrapper um eine WebView-Komponente des OS: Auf Windows ist das WebView2 (Edge), auf macOS WKWebView, unter Linux WebKitGTK – beide basierend auf WebKit.

JxBrowser bringt dagegen eine eigene Engine mit – basierend auf Chromium. Das Ziel: konsistentes Verhalten über alle Betriebssysteme hinweg, unabhängig von der Systemkonfiguration.

Browser-Engines: vom Betriebssystem bereitgestellt vs. mitgeliefert.

Browser-Engines: vom Betriebssystem bereitgestellt vs. mitgeliefert.

Entwicklungsaufwand 

Früher stellten Browser dieselbe Website oft unterschiedlich dar. Jeder Anbieter hatte eigene Varianten von HTML, CSS und JavaScript – das führte zu erheblichem Mehraufwand bei Entwicklung und Test.

Internet Explorer ist zum Glück Geschichte. Aber die Inkompatibilitäten sind nicht völlig verschwunden. Auch moderne Browser verhalten sich unterschiedlich – bei Rendering, Performance, Security.

Das SWT-Modell ist dafür anfällig. Eine plattformübergreifende SWT-App kann mit Edge, zwei WebKit-Varianten und verschiedenen Versionen davon konfrontiert werden. Je mehr Engines im Umlauf sind, desto höher der Testaufwand.

JxBrowser bringt eine feste Engine-Version mit. Entwickler wissen genau, welche Chromium-Version verwendet wird – unabhängig vom Betriebssystem. Die Version ändert sich nur beim Upgrade von JxBrowser.

Vergleich des Entwicklungsaufwands bei SWT-Browser und JxBrowser

Je weniger Browser, desto geringer der Entwicklungs- und Testaufwand.

Sicherheit und Updates 

Viele Firmen verlangen aktuelle Browser-Engines – aus Sicherheitsgründen. Allein in diesem Jahr wurden über 179 Schwachstellen in Chromium behoben – sechs davon mit bekannten Exploits.

Das SWT-Modell funktioniert gut in verwalteten Netzwerken mit erzwungenen Updates per Gruppenrichtlinie.

JxBrowser erlaubt es, die verwendete Engine-Version selbst zu bestimmen. So lässt sich die App unabhängig vom System aktuell halten – ideal für private Geräte oder unverwaltete Umgebungen.

JxBrowser liefert im Schnitt 15–20 Releases pro Jahr, jeweils mit aktualisierter Chromium-Version. Die aktuelle Version, JxBrowser 8.9.4, wird mit Chromium 138 ausgeliefert.

Funktionsumfang 

Das Browser-Widget ist funktional, aber durch die unterschiedlichen Engines eingeschränkt. Nur Funktionen, die mit WebView2, WKWebView und WebKitGTK kompatibel sind, können unterstützt werden.

Unterstützt werden:

  • Webseiten und lokale HTML-Dateien laden
  • Cookies verwalten
  • Popups behandeln
  • Basis-Authentifizierung
  • Java <-> JavaScript-Kommunikation
  • Listener für Titel- und URL-Änderungen

Vergleich des API-Umfangs von SWT-Browser und JxBrowser.

Die API-Fläche des eingebauten Browsers im Vergleich zu JxBrowser.

JxBrowser basiert auf Chromium, was die Unterstützung eines breiteren Funktionsumfangs erleichtert. Neben allgemeinen Funktionen zum Browsen stehen zahlreiche Chromium-spezifische Features zur Verfügung. Die folgende Liste ist nicht vollständig, zeigt aber zentrale Funktionen, um einen Eindruck der Fähigkeiten von JxBrowser zu vermitteln:

  • Chrome Extensions
  • Screenshots erstellen
  • Drucken
  • Formular-Autovervollständigung
  • Eigene Protokolle
  • Kontrolle über HTTP-Traffic
  • Erweiterte Authentifizierung (NTLM, Client-Zertifikate, SuisseID, U2F, Kerberos etc.)
  • und mehr

Kontrolle über den Browser 

Ein SWT-Browser ist mit einer Zeile erstellt: new Browser(...). Diese Einfachheit versteckt allerdings die Komplexität der zugrunde liegenden Technologie.

Wenn der Use Case simpel ist, ist das völlig okay. Wird es komplexer, braucht man mehr Kontrolle – genau die bietet JxBrowser.

Man startet den Hauptprozess von Chromium mit Engine.newInstance(...). Für mehrere Prozesse legt man mehrere Engine-Instanzen an. Diese sind komplett voneinander isoliert.

Innerhalb einer Engine gibt es Profile, die u. a. Caching, Proxy, Network, Downloads und Permissions kapseln.

Pro Profil können mehrere Browser-Instanzen erzeugt werden – vergleichbar mit Tabs im Browser. Sie lassen sich programmatisch steuern, auch ohne sichtbare UI. Anzeige erfolgt über BrowserView.

Jeder Browser enthält wiederum mehrere Frame-Instanzen, die jeweils einen HTML-Frame repräsentieren – inkl. Zugriff auf DOM und JavaScript.

Architekturdiagramm von JxBrowser.

Die Architektur von JxBrowser.

Entwickler-Tools 

Das SWT-API kennt keine DevTools. Man kann allerdings Edge- oder Safari-Tools verbinden – aber nicht unter Linux.

JxBrowser bietet eine API zum Öffnen der Chromium DevTools – auf allen Plattformen. Erweiterungen wie React DevTools lassen sich einfach installieren.

The SWT Browser API has no notion of developer tools, but you can connect those of Microsoft Edge or Safari to the instance of the Browser. Developer tools are not available on Linux at this moment.

JxBrowser stellt eine API zur Verfügung, mit der sich die Chromium-DevTools auf allen Betriebssystemen öffnen lassen. Zusätzlich können Entwicklertools-Erweiterungen für beliebige JavaScript-Bibliotheken installiert werden, um ein natives Debugging-Erlebnis wie in Google Chrome zu ermöglichen.

Screenshots der DevTools mit geöffneter React-Erweiterung

DevTools mit geöffneter React-Erweiterung in JxBrowser.

Automatisiertes Testen 

Automatisiertes Testen von Inhalten im SWT-Browser ist derzeit nicht möglich.

JxBrowser unterstützt Frameworks, die mit dem Chromium DevTools Protocol arbeiten – z. B. Selenium, Puppeteer oder Playwright.

Support und Hilfe 

SWT ist ein Open-Source-Projekt. Bei Problemen kann ein Issue auf GitHub gemeldet oder ein eigener Beitrag geleistet werden (Contribution Guide).

JxBrowser ist ein kommerzielles Produkt für Unternehmen mit hohen Anforderungen an Zuverlässigkeit und Support. Ein privates Ticketsystem mit garantierter Reaktionszeit (ein Werktag, SLA) steht zur Verfügung.

Der technische Support umfasst Nutzung, Fehlersuche, Fehlerbehebungen und die Prüfung von Feature-Wünschen. Alle Anfragen werden direkt vom Entwicklungsteam bearbeitet.

Spinner

Sending…

Sorry, the sending was interrupted

Please try again. If the issue persists, contact us at info@teamdev.com.

Read and agree to the terms to continue.

Your personal JxBrowser trial key and quick start guide will arrive in your Email Inbox in a few minutes.