Air Traffic Control, HTML Display, and JavaFX

From the point of view of existing Java desktop applications in the corporate world, I believe that the most significant part of JavaFX is its WebView (a.k.a. JWebPane) component. I write "I believe" because I have no real statistics, other than anecdotal evidence, to back me up.

I was reminded of this yet again yesterday, while walking around at ATC Global, the annual air-traffic control conference, which is the largest of its kind, held annually in Amsterdam. I met some of the developers from the LAIC Group, who showed me their air traffic control solution, which was originally created for Air Traffic Planning Controllers by the Air Navigation Services in the Czech Republic:

Look at the screenshot above. What you see is a Java Swing application. The main area shows a flight display of air traffic in the Czech Republic. Each point on the map, representing an airfield, can be clicked. When clicked, a browser opens, displaying airfield data... in an HTML browser. Part of the data displayed in the browser is static, while other parts are dynamic, supplied by the currently selected airfield. Performance is paramount in these kinds of applications, i.e., when something is clicked there needs to be an immediate, instantaneous response. Not only that, but the air traffic controller needs to be absolutely certain that there will be an immediate response, i.e., reliability & performance are essential.

At the time that the application was being developed, the best HTML browser identified for the purposes of this application by the development team was ICEbrowser. At the end of 2009, that browser stopped being developed and, apparently (this is what the developers on the LAIC team told me), it only worked with Java 1.4.

Essentially, their choice of browser has prevented this application from being moved away from 1.4. Rather than looking for another browser, they'd rather wait until the JDK provides a standardized one. It certainly is preferable to have a standardized component to getting one from a 3rd party, as the ICEbrowser experience learns. However, LAIC first heard about JWebPane back in 2008. "We were excited about it, at the time," they told me. "But now..."

Now, not so much, since it still does not exist. Which brings us to JavaFX. By being able to drop WebView directly into their application, this team will be able to move from 1.4 directly to 1.7, all thanks to the availability of standardized web browser support.

The point of this blog entry is simply to point out how important WebView is to commercial applications. Forget the animations, the interesting circles, the whizzbangywhatnots, just give corporate developers what they need, which simply is a standardized web browser. (Oh, and also something better than JMF, but that's also part of JavaFX.) Aside from those things, for corporate applications anyway, Swing is fine.


Yesterday, I was reading stuff about Orion Eclipse's initiative. Orion includes some Java parts and some web parts, see

It leads me thinking about Swing and GWT, and then, JWebPane.

What I thought yesterday is that if I needed to implement myself today another Java-based GUI layer, I would plug its roots into a lightweight browser and I would extend this browser to render non-standard UI (Java) components through redirecting browser painting orders towards the Java layer for those components. Because I think it's less work to stand on top of the shoulders of such a browser for implemenenting the base of GUI layers (standard components, layout, etc.).
Indeed, a browser is these days quite a beast to fight against: such a browser improves every day, and it's hard to fight existing HTML-related standards: HTML, CSS3.

So, I am happy to see JWebPane resurrecting, mixing Java+web strengths, because imho there is little room outside such a (clever) mix...

Posted by Dominique De Vito on March 10, 2011 at 11:07 PM PST #

Is it planned to display Java components (among other HTML components) inside a page rendered by WebView through WebKit/Java integration ?

Or is WebView only able to display HTML components ?


Well, future JavaFX sounds like a better choice than Swing for UI desktop development, that is, it sounds like Swing's next version.

Posted by Dominique De Vito on March 10, 2011 at 11:37 PM PST #

There is also flyingsaucer ( an XHTML renderer. Pretty nice, but no javascript. This shouldn't be a big deal since it mostly used for "rich" r/o rendering.

Posted by Jean-Marc Borer on March 11, 2011 at 01:08 AM PST #

I completely agree on your estimates from a "corporate environment", my experience is that Swing generally poses a very good solution for that kind of developments.

Again +1 to the impression on having a proper "web browser kinda" component as an increasing demand for those environments too. And, also, being able to integrate media content (audio, video) into many enterprise desktop applications is also a must nowadays. I'm thinking, for example, for medical, surveillance, monitoring, etc.

So, for me, this is what I'd value the most (and not only) from JavaFX:

- Web content integration \*and\* interaction
- Competitive media programming stack
- Easy integration of Swing <-> JavaFX stuff

Bonus: Native JavaFX integration into the NetBeans Platform. Killer feature!! ;)

Posted by Miguel Garcia-Lopez on March 13, 2011 at 08:27 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« July 2016