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.
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.
Hi, i have embedded webview component together in my swing application. The scroll bars look differently. Is there any chance to get one “Look and feel” like what we have in Swing application?
Having just played with a startup’s prototype of a JavaFX application, and having taken a thread dump and noticed 45 threads blocked in Socket.read(), it seems like the biggest thing you could do is to adopt async NIO for your socket I/O (both Netty and Apache HttpAsyncClient are good, or could at the least provide inspiration).
It seems like the world is moving away from one-thread-per-socket, and particularly in a desktop app, threads aren’t cheap – so this would improve footprint dramatically. From the thread dumps I saw, it looks like all of your I/O is inside the Java process, so you’ve got the ability to do such a change transparently; and if you don’t do it early, you’ll end up with people writing code that subtlely depends on the current threading model.
I also 2nd Tim’s comments. I recently emailed you directly. I’m hoping we can get you involved with some of these problems and figure out what is going on.