Joshua Marinacci's Blog

Competition and the Java Ecosystem: why Sun launched the PDF Renderer and Scene Graph projects

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!

Comments

• "If there wasn't enough interest then it was best to just let it die."I beg to differ. Code creates interest.

  Posted by: coxcu on December 20, 2007 at 08:28 PM

• I'm much more interested in the scenegraph, but because I work for a commercial company I can't touch GPL with a 10' pole. In fact, I submitted a paper to JavaOne that explores my company's solution to the scenegraph-tied-to-data issue. (Interestingly, our scenegraph is also heavily influenced by Jazz.) I'm not sure if recent developments have made my JavaOne submission irrelevant or several times more relevant, but it's an exciting time to be involved in these issues, and I hope I can contribute once the scene graph is really open (and not just GPL'ed).

  Being able to embed Swing was important. Our scenegraph also makes heavy use of the ability to scale to something other than 1.0, so we had to hack up Swing quite a bit to make it comply. I'm hoping that in the not-to-distant future we can throw it all away and join the Sun JavaFX/Scenegraph community, though.

  The single biggest issue holding a workspace/scenegraph-based Java app back, though, is the heavyweight/lightweight mixing problem. It's been the bane of integrating anything into our workspace for years-- I'm desperately hoping that feature gets backported from JDK7 to JDK6uN.

  Posted by: samkass on December 20, 2007 at 08:39 PM

• (Sorry about the jumbled text... I forgot that I'm typing in HTML here and that blank lines get nuked.)

  Posted by: samkass on December 20, 2007 at 08:40 PM

• all proprietary software companies will sooner or later have to compete with opensource alternatives - that comes with the territory now. From the likes of Microsoft, Oracle, Sun et al, down to smaller companies eg. JPedal. Having said that, i wonder if it wouldn't be better having Apache license, not least to soften the blow and reward such small propertiary incumbents, in that they can reuse some of code in their proprietary offerings, to make their product better?
  PS. i think companies still offering proprietary solutions should start moving to opensource, to preempt the inevitable. That is to say, for example, introduce a "community opensource version" and charge for premium version, service, or something like that. Those companies that don't have to foresight to start such a transformation timeously, shouldn't moan and cry when they are made less relevant by opensource competitors :(
  

  Posted by: evanx on December 21, 2007 at 02:22 AM

• The SceneGraph is very welcome, I hope you have plans to rewrite Nimbus on top of it. The current implementation of Nimbus, as I understand it, is all vector-happy but doesn't use any scenegraph, so it's not amenable to tight integration with native vectorial toolkits like WPF / Quartz Extreme / Beryl etc. - and we really need this (Swing being a first-class citizen in these new desktop technologies)... SWT is already there with the new port for Vista's WPF. Run Sun, run! :)

  Posted by: opinali on December 21, 2007 at 04:58 AM

• evanx:

  Multivalent is Open source under a BSD only license and JPedal has an Open source version under GPL (community opensource version and charge for premium version as you suggested). They have both been around since at least 2002 so there has always been an OS alternative to the commercial ones.

  The commercial only libraries are from Qoppa, BigFaceless, Icesoft and Crionics.

  If you use JNI, you could also plumb into xpdf, also open source under a GPL, or even Acrobat reader. So developers are spoiled for choice on Java...

  Apache license isn't really relevant because all of those more or less have the featureset of Sun already and do things in a specific way. Most interesting use would be to help with debugging if it works in Sun code (PDF spec is rather a law unto itself really and then you have Adobe, Ghostscript, PDFlib, Fop,etc interpretations of it).

  Posted by: markee174 on December 21, 2007 at 10:38 AM

• all proprietary software companies will sooner or later have to compete with opensource alternatives

  
  I agree. However, I don't think open source winning that competition is a foregone conclusion. In fact, I'm trying to think of an area where open source is winning when they directly compete against proprietary products. I think the biggest strides happen in areas of open source where they can work closely with proprietary business (ie. Apache license, MySQL-style dual license) and where it's completely decoupled license-wise yet serves as a foundation (ie. Linux). I've never seen a GPL library so compelling that it's influenced the decision of a company to open-source anything that has to link to it.

  
  In any case, open source is really nice to have as a "lowest common denominator" in industry. You know the state-of-the-art, no matter who goes out of business or acts against the public good, will never go below what's available via open source. But you get what you pay for, and even the most advanced open source projects tend not to be especially valuable to industry until they're tied to an expensive support contract. Since (and this is my own opinion so flame me elsewhere) open source tends to imitate rather than innovate, in my mind they act as the "sweepers" that make sure the older stuff is never lost, which I actually think is very valuable.

  
  Anyway, I don't want to get into a huge open/closed battle here. Just pointing out that the scenegraph API would likely get submissions and bugfixes from my (closed-source) company if they had a more open license than the very restrictive GPL. And if my company could someday throw away our own API and pool our resources with a future open Scenegraph, they'd be drinking from the fire hose (our scenegraph is used in a multi-million dollar Army program, among others.)

  Posted by: samkass on December 22, 2007 at 10:04 AM

This work is licensed under a Creative Commons License.