It’s been a busy few weeks for me with JavaOne Japan in early April, a heap of development work on JavaFX 2.2, and JavaOne India coming up next week. I’ve slightly dropped the ball on interviews during all of this, but here is another interview from a member of the JavaFX team at Oracle. Peter Zhelezniakov is an engineer in the WebView team, where he works on WebView-related JavaFX APIs all the way down to working with the Webkit code that WebView uses under the covers. Enjoy – and feel free to ask WebView related questions here – I’m sure Peter will be happy to help. 🙂

Hi Peter – thanks for offering to be interviewed. Could you please introduce yourself?
I came to the JavaFX team from Swing, where I was working mostly on Look-and-Feels, but also on Swing’s own HTML package.

So you work on the WebView feature of JavaFX. This is a major component of the new JavaFX 2 series of releases – could you please give an overview of what exactly WebView is?
WebView is a JavaFX node used to display Web pages, with the help of the underlying WebEngine object. It is basically a browser component with a richer programming interface: you can for example examine structure of a page, inject arbitrary scripts, or listen to HTML events. Internally it is a Java wrapper around the Webkit open browser engine used by many desktop and mobile browsers.

What does a regular day entail for you?
It varies wildly, from tracking down a bug to planning future work to speaking at conferences. Probably the only thing I do regularly is code reviews. Otherwise I try to break my time into large chunks spent on a single task, and switch tasks when they take too long to complete. After a day of debugging it’s good to spend a day talking to customers and discussing new features with teammates.

What I find interesting is that WebView uses JavaFX to render web content – is this difficult to implement, or does the underlying webkit make this easy to implement?
Implementation is straightforward in most cases, but still a lot of work as Webkit has maybe 60 or 80 different types of rendering requests that we need to implement. Some of those requests cannot be mapped directly to a Prism call, in which case we have to write glue code. However feature-rich Prism is, Webkit with its support for CSS3 may have even fancier architecture when it comes to rendering.

My understanding is that WebView is a continuation of the work that previously went on with the never-released JWebPane. Did this work make WebView development easier?
It surely did. JWebPane was wrapping Webkit as a Swing component, a Swing-based analog of WebView, using Java2D for rendering. The team gained precious knowledge about Webkit intrinsics while working on JWebPane. Once we switched to JavaFX, all we had to do was to rewrite rendering code using Prism. That was still lots of work, considering how architecturally different Java2D and Prism are, and Webkit’s own rendering interface resembles Java2D more than Prism. Also Prism was a moving target at that time, changing frequently, and poorly documented. But at least we knew WHAT our code should do, and had to figure out just HOW to write it.

What is working with webkit like? Are you required to make many changes or is it good to work with as-is?
We try not to change Webkit code when possible, as this complicates merging changes to Webkit with our code. Fortunately Webkit has well defined cross-platform core that we almost don’t have to touch. Webkit is ported to many different platforms, from desktops to phones, and each new port helped to refine the boundary between the core and “client” interfaces that ports need to implement in platform-specific code. So while we have lots of code in the client part, our changes to the core are kept to a minimum.

I often see changesets pushed by you or your team mates designed to fix a rendering bug exhibited on a certain website. Why does this happen, and more generally, how hard is it to have a job requirement that your product support rendering the entire internet?
This happens because there are lots of corner cases in the rendering system. We may show 99 sites perfectly, but the 100th site hits a corner case that was not implemented, or a bug in our code, or even in Webkit. Recently we were fixing a bug that was reproducible with one particular site. That site used one pixel wide gradient images to store colors, which were later scaled appropriately. It turned out our code didn’t handle those one pixel wide images correctly (two pixel wide ones were fine). This bug existed for about half a year, and went unnoticed until an external customer raised an issue. So the hardest part to me is testing, especially regression testing. We have an automated test suite, and try to expand it, but the scope of auto testing is really limited in our case. So we try to identify sites that test many things at once. Canvas games and SVG animations prove useful as they make extensive use of the rendering system. We’ve written a pretty functional browser demo, with tabs and bookmarks, and people are using it for everyday browsing instead of their favorite browsers. This way regressions are noticed soon after they are introduced.

I believe that WebView already supports Java to JavaScript calls. However, an area that a team mate of yours, Per Bothner, is working on is JavaScript to Java communication. What would this kind of bidirectional communication allow?
Yes, the idea is that an application developer establishes an “interface object” in Java code and makes it known to the JavaScript engine. It is then possible to call methods of that interface object from JavaScript. This enables a new kind of mashups, when a Web application uses features of the Java platform. E.g. a click on a map could run a database query on the Java side, on the client, without calling back to server. Or a Web app could display local resources, such as images or music files, along with those stored on a server.

What do you really, really want to see in future releases of JavaFX?
I’d like to see JavaFX proliferate across more platforms, including phones, tablets, kiosks, whatever devices people routinely use. May it become a truly ubiquitous programming platform — just like Ajax but more convenient to use.

Thanks for taking the time to answer these questions Peter. Is there anything else you’d like to conclude with?
I’d like to thank all developers who have tried our bits, filed bugs and provided feedback. It’s very important that we hear from you.