The WebRenderer Swing Edition changes the face of Java Swing applications and the rendering of Web content within Java. Before we jump into that, let's take a look back at Web content display in Java desktop applications including the generational changes and Java's very own "Browser Wars."

The date is August 26, 1997. The Netscape Corporation announces1 that they are working with Sun Microsystems to release "a 100% Pure Java version of Netscape Navigator client software by 1998." The Java community rejoices. Along comes 1998 and nothing but silence. Was it just me who missed the release of Netscape Navigator Java Edition? Who pulled the plug and why? A decent Java browser SDK back in 1998 would have gone a long way toward popularizing Java on the desktop. Instead, we're left with more than a few beers short of a six-pack.

Java on the desktop has always been somewhat lagging. First, Swing was plagued by a bad image surrounding speed. Then there was poor platform L&Fs, bugs in essential components such as the File chooser, etc., and now in the year 2007 Swing still lacks pure Swing industrial-strength Web content rendering. This fact alone has driven many Java rich-client developers to either seek out third-party components or change the direction of their desktop application development and write their rich client applications in an alternative language that supports standards-compliant rendering, or (and this is the worst) utilize nonstandards-compliant Java browser SDKs and craft the Web content input around the failings of the Web content rendering engine. This paradox was always confusing. Java Web content rendering engines were written to display Web content, but in the end the Web content had to be modified to work around the failings of the Java browser SDKs. Figure that one out!

While Web standards have improved the look and feel of Web sites through CSS and JavaScript and interactivity has increased through AJAX, Java enterprise Web applications have boomed, but Java still lacks quality Web content rendering for its Swing toolkit. How could this important detail be omitted in the decade of the Web boom?

Through all this mess, over the last decade a budding community of ISVs and large software vendors have taken the challenge with open arms and developed their own Java browser SDKs of varying architectures and with mixed results spawning their very own "Browser Wars."

First-Generation Web Content Rendering
Web content rendering in Java started life as a clean room, pure-Java implementation of an HTML parsing engine and utilized Swing drawing routines to render the graphics. The Sun default Java implementation (JEditorPane) was, and still is, basic and did not support any standards outside basic HTML, so various companies developed "commercial-strength" pure Java browser SDKs. These SDKs followed the same paradigm as the default Java implementation, but extended this to support JavaScript and other Web standards. The key limitation of pure Java browsers is they do not live up to the rendering standards delivered by Firefox and Internet Explorer.

The sheer scale of Web standards meant that small private companies in the Web content rendering space had to hire small armies to develop anything that was remotely standards compliant. Then there were issues with dynamic content such as JavaScript, and additional Web styles such as CSS 1 and 2. The task of developing a pure Java browser was and still is monumental. A standards-compliant pure Java browser is not a commercially viable prospect. The first-generation Java browsers ended up with a lightweight implementation that often "broke" on real-world Web content. Due to this fact, first-generation Java browsers are slowly dying out with the major vendors withdrawing support, paving the way for a new wave of Java browser SDKs.

Second-Generation Web Content Rendering
This first round of Web content rendering engines can be referred to as first-generation rendering engines. The next step in the development of Java browser SDKs was brought to life by JadeLiquid Software, which developed the WebRenderer Desktop Edition, a commercial-strength, native-based Java browser SDK. The release of the first second-generation, Web content rendering engine occurred back in 2002 with the release of the WebRenderer Desktop Edition. The development affected the face of Web content display in Java by bringing the market-leading native browsers (Mozilla, Internet Explorer, and Safari) through to the Java environment for use in Java rich client applications. Many copycat developments, including some from the Java industry giants, have followed and the trend for Java browsers has headed toward the architecture pioneered through the WebRenderer Desktop Edition. The key limitation of second-generation native Java browser SDKs is that they are heavyweight. Being heavyweight, on many occasions they don't play well with the Swing toolkit. While the rendering is phenomenal and standards compliant, Swing integration can be somewhat tricky. Standard JFrames, JPanels, etc., are fine. The integration issues rear their head with JInternalFrames, JTabbedPanes, Glasspanes, JMenus, and the like. The heavyweight-lightweight mixing issue has always created issues for Swing. The WebRenderer Desktop Edition provides a compatibility layer to help with Swing integration but, by design, lightweight and heavyweight components don't mix well together. Despite the integration issues in the commercial space, the second generation of Java browser SDKs have proven themselves as the architecture of choice for commercial grade Web content rendering. Now that you have the history, where to from here? Well, JadeLiquid, the developer of the WebRenderer family of products, has just released a new product that will change the Java browser SDK space and create the third generation.

The Final Frontier
Now that the Java "Browser Wars" are moving toward a conclusion, with the native architecture base winning out for enterprise desktop applications, it will be interesting to watch this space and see what companies, such as Sun Microsystems, do to embrace or "reinvent the wheel" in the eye of the third-generation Java browser SDK, WebRenderer Swing Edition. Sun's latest attempt at building a Java browser SDK (the JDIC program) has been flailing with mixed results. The architecture direction is blatantly wrong and major issues are a dime a dozen. Through the architecture of JDIC Swing compatibility is limited (see second generation) and with time the second generation is destined to end up like the first generation. Word from the Java rumor mill is that Sun's JEditorPane is undergoing some tweaking. Without years of development and a team larger than the entire J2SE team, this is a losing and some would say pointless battle. At best some JEditorPane revisions will result in yet another substandard first-generation browser component or at worst a better version of a broken wheel.

Is WebRenderer Swing Edition the only commercial strength option for "real-world" Web content support within Java Swing applications? You decide.

References
• http://web.archive.org/web/20031014110817/
http://java.sun.com/pr/1997/august/pr97826-02.html
• www.webrenderer.com

SIDEBAR

Third-Generation Web Content Rendering
The WebRenderer Swing Edition is a pure Swing Java browser SDK based upon native parsing and layout of the Mozilla engine (the exact same parsing and layout engine as utilized by Firefox). What does this mean? It means that now Java Swing applications will have commercial-strength Web content rendering in pure Swing. Every line, polygon, image, text, and more will be drawn in pure Swing. The WebRenderer Swing Edition has removed the heavyweight rendering of the native layout and rendering engine. This will provide Java Swing applications with Swing integration and industry-standard rendering.

The rendering quality of Mozilla is paired with the lightweight drawing of Swing, including support for Java Look and Feels (L&F). This means seamless integration into Swing applications with the standards compliance of Mozilla. No longer is there a great divide between Swing and real-world commercial strength Web content rendering. WebRenderer Swing Edition is the first of the third generation of Java browser SDKs. Not only is HTML, CSS 1 & 2, JavaScript (including AJAX) supported, but Java applets and third-party plugins such as Flash are supported. Enterprise technology mash-ups including Java, Web content, AJAX, Flash, and Swing are now possible in a single Java Swing application.