When you need to display web content in an SWT application, you typically have two choices: the built-in Browser widget or a commercial option like JxBrowser.
This article breaks down the differences between the two, and helps you choose the right one for your needs.
In a nutshell
The built-in Browser is a simplistic but capable widget that uses the browser
engine provided by the operating system. Choose Browser when:
- You have to use free software.
- The use case is simple and non-critical.
JxBrowser is an advanced commercial web view control based on Chromium. Choose JxBrowser when:
- The use case is complex or critical.
- You need to control the browser engine version.
- You need a consistent browser engine across platforms.
- You need to test web content in SWT automatically.
- You need one of the advanced features.
- You need support, bug fixes, or custom features.
Embedding
Given the Browser widget is part of SWT, it’s very easy to embed it into
your application:
var browser = new Browser(shell, SWT.NONE);
browser.setUrl("https://example.com");
With JxBrowser, you must first add the dependencies to the project. Based on your build system, you can use Maven artifacts, add the JAR files to the classpath, or create a standalone Eclipse plug-in.
Once you added the library, the embedding looks like this:
var engine = Engine.newInstance(HARDWARE_ACCELERATED);
var browser = engine.newBrowser();
var browserView = BrowserView.newInstance(shell, browser);
browser.navigation().loadUrl("https://example.com");
Browser engines
The original idea behind the Standard Widget Toolkit was to provide a user experience that feels native to the operating system. To achieve that, SWT uses widgets provided by the operating system, instead of creating its own set of widgets as other toolkits typically do.
Therefore, every widget in SWT is a wrapper over the native counterpart. The
toolkit gives you an API for using the widget, but the operating system handles
rendering, accessibility, focus management, and other things. The Browser
widget works this way, too.
The Browser is a thin wrapper over a web view control provided by the
operating system. On Windows, that is WebView2, based on Microsoft Edge.
On macOS and Linux, these are WKWebView and WebKitGTK, respectively — both
use WebKit.
JxBrowser, on the contrary, comes with a built-in browser engine — based on Chromium. The idea is to ensure consistent browser behavior regardless of the operating system and installed software.
Browser engines: provided by the OS versus bundled.
Development costs
In the past, the browsers often rendered the same websites differently. Browsers from different vendors supported their own subsets of HTML, CSS, and even JavaScript. That staggering incompatibility between the browsers resulted in excessive development and testing efforts. That was a constant source of problems.
Internet Explorer is now long gone. Thankfully. But have the incompatibility issues disappeared with it? Sadly, no. The browsers keep upsetting developers by executing their code and rendering their styles differently.
The SWT approach is susceptible to this very problem. In the wild, a cross-platform SWT application may not only meet Edge and two flavors of WebKit but also numerous versions of them. One thing is clear: the more browser runtimes are out there, the more development and testing efforts are needed.
JxBrowser comes with a built-in browser engine. This way, developers know the exact version of Chromium the application uses. The version remains the same for every operating system and only changes when JxBrowser is upgraded.
The fewer browsers — the fewer development and testing efforts.
Security and updates
Many companies demand that the browser engine be up-to-date. That is a security requirement, and it is a reasonable one. Chromium fixed more than 179 vulnerabilities this year alone. Six of them have known exploits.
The SWT approach of using the system browser works well in managed corporate networks, where timely updates are enforced through domain policies.
The JxBrowser gives developers control over the browser version. This way, the application can guarantee compliance with the company policies and not depend on the environment. This approach works well in unmanaged networks or with personal computers, given that the application is upgraded appropriately often.
In 2024, JxBrowser released 15 versions with Chromium upgrades. The latest release, JxBrowser 8.2.1, comes with Chromium 131.
Features
The built-in Browser is a capable widget but is limited by its own
architecture. Using different browser engines limits the API to the features
that are compatible between WebView2, WKWebView, and WebKitGTK.
The Browser allows you to:
- load websites and local HTML files;
- manage cookies;
- manage pop-up windows;
- perform basic authorization;
- call JavaScript from Java and vice versa;
- listen to the event when the page’s location or title changes.
The API surface of built-in browser and JxBrowser.
JxBrowser uses Chromium under the hood, which makes it easier to sustain a wider range of features. Besides generic browsing features, it offers features specific to Chromium. This list isn’t complete, but it showcases key features to give you a sense of JxBrowser capabilities:
- Chrome extensions.
- Taking screenshots.
- Printing.
- Form autofill.
- Custom protocols.
- Control over HTTP traffic.
- Advanced authentication (incl. NTLM, SSL client certificates, SuisseID, U2F, Integrated Windows Authentication, and Kerberos).
- and more.
Control over the browser
It takes one simple line to create an SWT browser: new Browser(...). But
the simplicity of this line conceals the actual technology’s complexity.
The underlying browsers are very complex projects. They have different process
models, security features, and their own approaches to embedding into other
platforms, like SWT.
When the needs are simple, we want this complexity hidden. However, greater control over the browser may become necessary when things get serious. The hierarchy of concepts provided by JxBrowser API gives you this control.
The architecture of JxBrowser.
You start Chromium’s main process by creating an Engine. If you need five main
processes, you create five instances of the Engine. Objects created within one
engine are physically isolated from other engines.
Within every engine, you have one or more Profile’s. These are Chromium
profiles that allow keeping all browser data and settings separate. You can
manage cache, proxy, networking, downloads, permissions,
and other features on the profile level.
Within a profile, you create multiple Browser instances — think of them as
tabs in Chromium. These are the actual browsers that let you navigate, dispatch
mouse and keyboard events, take screenshots, open DevTools, and
do other things. The browser is fully functional even when
it’s not visible to the user, as the rendering happens in memory by default. To
show the browser, use BrowserView.
Finally, there can be multiple Frame instances in a browser. They represent
actual frames on the page and allow you to work with
JavaScript and DOM.
Developer tools
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 provides an API to open Chromium’s DevTools, which works in all operating systems. You can also install developer tools extensions for any JavaScript library and have native developer experience, just like in Google Chrome.
DevTools with the React extension in JxBrowser.
Automated testing
The automated testing of web content loaded in SWT Browser is
currently impossible.
JxBrowser is compatible with automated testing frameworks that support Chromium DevTools protocol, such as Selenium, Puppeteer, or Playwright.
Support and assistance
Since SWT is an open-source project, you can always count on the community. If you find a bug or think of a nice feature, share your findings on GitHub, and feel free to contribute.
JxBrowser is a commercial product created for companies with deadlines and high requirements for third-party software and vendors. We offer a private helpdesk system where reports from clients remain confidential. The guaranteed first response time, or SLA, is one business day.
The technical support includes help with product use, assistance with troubleshooting, bug fixing, and considering feature requests. All your support requests will be processed directly by JxBrowser software engineers.
Sending…
Sorry, the sending was interrupted
Please try again. If the issue persists, contact us at info@teamdev.com.
Your personal JxBrowser trial key and quick start guide will arrive in your Email Inbox in a few minutes.