Josh On Design

I'd like to take a second out of my usual technical blogging to discuss something important. Sun recently launched two new open source projects: the Scene Graph and PDF Renderer projects. In both cases some readers wondered why Sun felt the need to start new projects rather than contribute to or recommend existing open source and commercial projects. Is Sun opposed to commercial Java software vendors? Do we insist on reinventing everything ourselves? The answer is an unequivocal no. Each new project inside Sun goes through a rigorous vetting process to determine what projects to start and how. Today I'd like to let you see inside our brains and find out why we launched these new projects.

the code came first

I'll start with the PDF Renderer. There are many existing PDF renderers out there, some open source and some closed; some written in Java and some in C. So why did we decide to start a new open source renderer when there's already a bunch out there? The answer is: we didn't!. We didn't sit down one day and decide to launch a new difficult project. The reality was much different, and stranger. The code came first.

Several years ago researchers inside Sun Labs created a PDF renderer because they needed an all Java PDF viewer for content created by Open Office. The library had to be written Java instead of a C wrapper because it had to work on every platform (and JNI wrappers have their own problems). It had to work under a license compatible with Sun's internal projects, so GPL was out. It also only had to read Open Office output so writing it would be easy (isn't that how they always start!). Given these constraints it made sense to write a new library.

Now fast forward a couple of years. Sun Labs has finished the internal project and doesn't need this library anymore. Since it was graphics related they asked the Swing team if we would like to use the code for our own projects or open source it. Richard Bair and I immediately said: yes, we want it! We had received numerous requests for a PDF renderer as part of SwingLabs (I think Rich even started on his own library at one point).

For two years Rich and I worked to get the code released, following up on all possible patent issues and finding resources to support the new project. Because we specifically didn't want this to be another "throw the code over the wall and forget it" exercise we decided to launch only if we could find a non-Sun employee to run the project. If there was enough interest for the community to run it, then we would open the code. If there wasn't enough interest then it was best to just let it die. Fortunately, Tom Oke from Elluminate expressed both a professional and personal interest in the project, so a few weeks ago I went back to the approval board and received the official go-ahead.

I don't expect the PDFRenderer project to compete with some of the high quality commercial solutions already out there. Many have done a terrific job of supporting every PDF file and feature they can get their hands on. There is enough room for more than one PDF library in the Java ecosystem. In fact, diversity and creative competition is what makes the Java ecosystem thrive. I wouldn't change it for the world.

the need came first

While the PDF Renderer was created because the code came first, the Scene Graph library was created because the need came first. The need was JavaFX Script (which is targeted toward a different audience). While I love the fact we have open sourced the scene graph and can code against it with Java, the primary reason for it's existence is JavaFX Script.

In the world of scene graphs there are many options. In fact JavaFX Script was originally built atop one of them: Jazz. We considered continuing to develop Jazz or it's successor Piccolo, but decided against it because they didn't fit the following constraints:

• Have a clear history of all copyright and patents in the library so we can indemnify Sun's customers.
• Have a license compatible with eventually moving it into the core JRE (which we hope will happen one day).
• The ability to transform Swing components, both input and drawing.
• Be smaller with an API tuned to the needs of JavaFX Script.
• Have internals compatible with the heavy duty graphics tuning we have planned (think pixel shaders). We need something very high performance to compete with the other emerging RIA platforms.

It turns out that the initial implementation of a scene graph isn't very difficult. You could build an initial version in a few days thanks to the support provided by Java2D. The tricky part is getting the API right. Even though we didn't adopt the code from Jazz or Piccolo (or even the NetBeans Visual Library), we did learn a lot from their APIs and how people use them. There are clear influences. It was not our intent to supersede those existing projects. We built what we needed for JavaFX Script. In the future, I hope that enterprising developers will build bridge layers allowing existing programs to use a new implementation built on the Scene Graph.

So there you have it. Two different open source projects created for two very different reasons. In both cases we actively support diversity and competition in the Java ecosystem. It's what makes Java great. Have a happy 2008!