Richard Bair's Blog

SwingLabs and Swing

In my last blog's comments Andy Roberts asked the following question:

I always keep my eye on SwingLabs because it is adding great value to the existing Swing toolkit. One thing that confuses me is just *how* it interacts with Swing, within the development process, that is. SwingX is an incubator for neat features, for example, sortable tables. Yet the approach adopted by Swing devs in Mustang is different than that in SwingLabs. And license issues seem to be contradictory, with SwingLabs being LGPL, it can't ever be absorbed into the main Java code. I've personally communicated to Richard discussing this, but it would be worthwhile clarifying fully the interaction between Swing and SwingLabs for all.

The Short Answer

SwingLabs is simply an incubator for ideas that can be incorporated into Swing. Swing engineers work on both Swing and on SwingLabs (incidently, SwingX contributors include Scott Violet who is the Swing architect, and Josh Outwater who is a Swing engineer for Apple, as well as several other Swing engineers).

The Long Answer

There is a real need in the desktop java community for components and frameworks to aid in writing rich client Swing applications. This need is deeper than simply updating the Swing toolkit. Things such as a data binding framework, application framework, tool support, progress management, and so on are really not part of the Swing toolkit per se. Rather, they are built beside or on top of Swing to help make the Swing application programming experience better.

There are also many things which are directly related to Swing, such as our JXTreeTable component. Another example is the filtering, sorting, and highlighting support for trees, tables and lists. The JXDatePicker is another good example. Work on these components is directly related to the Swing toolkit.

This is a minor distinction that substantially alters the way that SwingLabs interacts with the JDK. Frameworks built around the Swing toolkit that are included in the JDK will go through a formal JSR process, while additions to the Swing toolkit itself will be done via one of the release JSRs (such as the JSR for Dolphin). This is more a matter of procedure, but is a good thing to keep in mind.

As I mentioned in the "Short Answer", SwingLabs was initially created as an incubator for Swing. It was a place that Swing engineers could test out proposed enhancements with the community. It's LGPL license ensured that any changes to the code would have to be publicly available, while also allowing developers to bundle the code with their proprietary applications.

But it didn't take long to notice that developers wanted to build Swing apps now and couldn't wait 18 months or longer for these changes to be made available in the JDK. I was one of those developers. Helping rich client Swing applications take root is a very important goal for the SwingLabs project.

If the project is LGPL, then how can it be incorporated in the JDK?

This is a legal question more than a techinical question, but I'll do my best to answer it with the general caveat that I am not a lawyer. However, as I understand it, when you write a piece of code there are two different kinds of rights that you get. The first is copyright. Copyright means that you own what you wrote the instant that you wrote it, and you have the right to do with it as you please. One of those rights is to assign a license to your work. The License dictates what rights others have with your work. However, as the copyright owner you have the right to be able to change the license at any time.

So, if a Sun engineer writes some code for the SwingLabs project, then Sun (who is paying the Engineer) owns the copyright for the code. It is licensed under the LGPL, but whenever Sun decides to change license we are free to do so, since we own the copyright on the code. What was originally released as LGPL is still LGPL, meaning that it is impossible for Sun to revoke your rights to the code that was released under the LGPL, but they can dual license the code.

What does this mean for the JDK? Well, it means that in order to migrate code from SwingLabs into the JDK we need to fork the code, change license, and put the new code into the JDK. Because Sun owns the copyright, Sun can do that

However, what happens if code is contributed from folks outside of Sun? In that case, there are a couple of concerns. First, as demonstrated above, in order for SwingLabs to fulfill it's mission as an incubator for Swing Sun must own the copyright, or the code could never be included in the JDK. However, since nobody would want to hand over copyright to their own work, we use a Joint Copyright Agreement for the SwingLabs project. The JCA grants joint copyright between you the contributor and Sun. You still maintain every right you once had, but you also grant Sun copyright ownership.

In this way, Sun is able to migrate code from the SwingLabs projects into the JDK.

If SwingLabs is an incubator, then why does the implementation differ between Mustang and SwingLabs?

In an ideal world, it wouldn't. Ideally new features would be implemented in SwingLabs first, and then simply included in the JDK rather than being rewritten. Unfortunately, due to time constraints this was not fully realized for Mustang.

Can SwingLabs be used with my proprietary application?

Yes!

Well, that's it for today. If you have any more questions, I'd be happy to answer them as best I can!

Comments

• The frustrating thing about LGPL is that, at least for java libraries, it doesn't do what the copyright holder expects it to do, which is to encourage people to use the libraries in proprietary and open source applications.
  The wording in the LGPL was selected with C code specifically in mind. Lawyers get understandably nervous about, say, subclassing LGPL'ed classes in proprietary code, or in open source code put under a different license.
  For example, the NetBeans project (licensed under the SPL) won't include the jdk14 backport of SwingWorker. Now, it's silly, because Sun isn't going to sue itself. But still, this highlights why LGPL is a bad license for java. The main reason is that it doesn't do what the author intends it to do. Potential users, in both proprietary and open source apps, look at libraries and say, "Oh, LGPL? Oh well, I guess we can't use it."

  Posted by: richunger on August 14, 2005 at 07:18 AM

• For example, the NetBeans project (licensed under the SPL) won't include the jdk14 backport of SwingWorker.
  That would probably have more to do with the Not Invented Here syndrome you see in many netbeans engineers.

  Posted by: zander on August 14, 2005 at 09:58 AM

• 
  Richard, thanks for writing this up. I think it does help those interested in SwingLabs to understand the relationship with Swing.

  richunger: there is much confusion over the LGPL. It's intention is clear but its wording is not. I can understand the anxiety, but rest assured that RMS made his case quite clear (http://www.gnu.org/licenses/lgpl-java.html).

  
  I hope this gets sorted out in the next update of the licenses as it's doing more harm than good. It's sad that L/GPL code now gets overlooked because of misunderstandings. I think the concept is pretty good as it helps Free code stay Free.
  

  Posted by: arooaroo on August 15, 2005 at 05:14 AM

• Rich: I know, getting a license that everybody agrees with is probably an impossible task. The good news is that since Sun holds the copyright, we can (at least in theory) dual license if necessary.

  Posted by: rbair on August 15, 2005 at 12:32 PM

This work is licensed under a Creative Commons License.