Welcome back to the XUL Titan Interview series. Today let's welcome Jazilla prodigy Mathew McBride.

Q: Can you tell us a little bit about youself?

Mathew McBride: I'm probably one of the youngest people around in the XUL world. I live in Australia, and I'm currently doing year 8 in high school. I've learnt almost all my skills in the IT area by myself.

Q: How did you stumble onto Mozilla's XUL?

Mathew McBride: I first stumbled onto Mozilla around Milestone 17 (if I remember correctly) in 2000. When Netscape 6 came out I was interested in seeing how its interface was themed and how the whole thing worked.

Q: How did you get started on Jazilla?

Mathew McBride: Back in 2002, I was involved in the flight simulation scene quite a bit. I decided to write a GPL'ed application and server backend in order to automate processing of data in Virtual Airlines. I needed a HTML renderer for parts of the project, and I didn't know JTextPane exisited at the time. Some googling turned up Jazilla, which was a long defunct project at the time. I spent a few days looking at the codebase and took over the project soon after.

Q: Can you tell us a little bit about Jazilla's history?

Mathew McBride: Back in 1998, Netscape was rewriting the entire communicator suite in Java, in an effort called "Javagator" (and "Xena" by some people). The effort, sadly ended up dying in the corporate warfare that was Netscape at the time.

When Netscape released the Communicator 5 source code (which is what we now call Mozilla), a group of eager Java hackers started "Jazilla", an effort to port the (ugly) C and C++ Mozilla code to Java. The project continued on for the next two years, producing two Milestones, but dying off in 2000. (See the Wired story for some history)

I had a look at Jazilla in August 2002 and decided this would be a perfect project to work on. I soon took over leadership of the project and rescued it from the dead.

In December that year, I started playing around with jXUL as it was very easy to hack on, and was already close to Mozilla's XUL spec. I had the <browser> tag implemented with JTextPane, and later NetBrowser (a fork of Jazilla's old rendering code which was somewhat cleaner than the code at the time the project died), which lead to Jazilla ("NextGen" - to seperate it from the older Netscape 4.x like releases) Milestone 1 last year.

Q: Can you briefly sketch out the Jazilla architecture and its building blocks?

Mathew McBride: Jazilla uses the W3C DOM and Xerces to parse XML into a DOM tree. Based on the elements on the DOM tree, a Java class set up to handle a particular element. These construct the equivalent Swing widgets which are displayed. Event handling is done via Javascript and Mozilla.org's Rhino JavaScript engine, and CSS is used to style widgets.

Q: Can you tell us some challenges you faced building Jazilla using Java and Swing?

Mathew McBride: There are some parts of the Mozilla XUL spec which I've already thrown into the "too hard for now" basket.

Implementing Mozilla's <splitter/> tag has proved to be hard (Swing's direct equivalent - JSplitter didn't support collapsing and JSplitPane is hard to use when we are constructing everything in real time with no indication of what the engine will have to process next).

Also, XUL Observers and Broadcasters are proving hard to implement, even though they are somewhat rarely used in the Mozilla suite.

Q: Can you tell us what Jazilla can do today? What works and what needs to be done?

Mathew McBride: In addition to my efforts to get Mozilla's browser suite working with minimal code rewriting, Jazilla can be used to create basic applications. The immediate use would be in the embedded devices area, even though desktop applications are possible and can be done, but needs more work in order to deliver more functionality.

In the future I hope to improve the XUL engine even more, and XPCOM components. Allowing SVG and HTML via namespaces in XUL is a to-do item.

Q: Can you tell us if it's possible to use Jazilla's XUL engine - jzXUL - for building "classic" standalone Java Swing applications? Do you have a separate distribution? What are the dependencies for jzXUL?

Mathew McBride: It's possible to build standalone Swing applications with jzXUL, and there aren't many external dependencies either (the CSS part of Apache Batik, Mozilla.org Rhino, A DOM parser like Xerces are as far as it goes). A seperate distribution (with all external libraries in the box, but without Mozilla chrome) will come about sometime in the future. I've recommended recently to people who want to construct XUL applications use the XUL challenge kit, as that has all Mozilla "chrome" (XUL files) removed.

Q: Can you tell us how you handle the mapping from XUL tags/attributes to Swing classses/properties? Do you use reflection? Do you use hand-coded glue code?

Mathew McBride: Mapping from XUL elements is currently done with hand-coded glue code in every element class. In the future construction of element classes will be done in a simular way to the HTML engine, by reflection.

Thanks Mathew McBride. Check back next week for the second part of the XUL Titan interview with Mathew discussing how jzXUL differs from its jXUL origins, what's the state-of-scripting in Jazilla, what the future holds for Jazilla, and much much more.

Links:

Jazilla Project @ http://www.jazilla.org