Why Opensourcing Swing Won’t Fix HTML

Rick Jelliffe holds the poor HTML support in swing up as an example of why Swing should be opensourced. There’s a very major flaw in this argument though: you’ve been able to fix the HTML support in Swing since at least Java 1.3 and probably well before. It was actually designed to be replacable. Just implement your own HTMLDocument and HTMLEditorKit and you can plug it into a JTextPane all you like and render HTML to your heart’s content.

So why hasn’t it happened? Because everyone wants someone else to fix the problem. Rendering HTML is hard, it’s a very complex standard and real-world usage makes it even more difficult. Opensourcing Swing won’t make the task any easier and it won’t suddenly bring a whole bunch of talented developers out of the woodwork that are happy to commit their time to fixing HTML support. If there were developers like that out there, they’d be working on Mustang right now – or more likely, would have been working on a replacement HTML renderer/editor for Swing way back.

Many companies have taken up this challenge, in the comments Patrick Wright mentions WebRenderer, the company I work for, Ephox, has written a better HTML editor based on the Swing text APIs and there are plenty of others out there.

Opensource isn’t some magical solution to developing software – it doesn’t make hard tasks suddenly simple, it doesn’t suddenly get the whole world working for you to develop your every whim. Opensource has its advantages but it isn’t the solution to a lack of developers to work on things. Even if you do get external developers working for free, you’ll probably spend just as much time building and managing the community as you would have doing the work. Opensource is great, it provides a huge range of benefits, just don’t expect it to magically do your work for you.