Richard Bair's Blog

August 2005 Archives

Every Project needs a Name

An invaluable tool for ensuring good API design is to, well, use your own APIs. I usually have a half dozen partially completed apps in my workspace which I use to test the SwingLabs components and APIs. Sometimes I find our code to be extremely helpful, and sometimes I find ...er... that they need more work.

One such project (affectionately named JavaApplication1) is a front end for IssueZilla. I was putting issues into the DataBinding project and just couldn't take it anymore. That web UI is horrible! So I wrote a quick and dirty rich client implementation.

In the process of writing this little app, I started testing some of the edges of our databinding APIs, and found places that worked really, really well and places that needed some more work. I thought this would be a very valuable project to have on java.net for a couple of reasons:

1) Demos are only worth so much. Until we have a full application built on the SwingLabs components, we won't really know how well our stuff works

2) An application available to SwingLabs developers to collaborate on would make the process of discussing use cases and edge cases much easier

3) The world could benefit by not having to use the IssueZilla web UI (*shiver*)

Which brings me to the difficult question of the day -- what should I call it?

Richard

PS> Why yet another bug-viewer/project management/whatever tool? Because I doubt I could convince somebody else with any legitimate code base to allow us to muck with it and rewrite the whole app to use SwingLabs components

PPS> No, this project is _not_ part of SwingLabs, so you don't have to be a SwingLabs developer or sign the JCA to develop for it. And yes, we'll be reusing other open source code whereever possible

Not Invented Here?

"Not Invented Here", a clever phrase often used as a pejorative to indicate that somebody (usually due to ego?) would rather reinvent the wheel and write their own implementation than leverage an existing (and by implication, better) implementation. In this entry I try to shed some light on real technical reasons why "rolling your own" may be better than relying on somebody else's implementation.

First, let me state that I am in favor of leveraging existing work whenever possible. It is often more economical to purchase tools than to build your own. It is sometimes more economical to purchase tools than use open source equivilents. It is sometimes wiser to use open source implementations than either purchasing or writing your own. Each circumstance and situation is different, there isn't one right answer for every situation.

Also, the opinions expressed below are from an API designer's perspective, not from an application developer's perspective. Some of the same principles can be applied, but it should be noted that an application developer's needs and goals are fundamentally different from those of an API designer.

I also want to go on the record and say that similar competing implementations are not always a bad thing. I agree with Romain's statement on his java.net blog:

First, creating a new and similar to another Open Source project is not reinventing the wheel. No matter how close two projects can be they'll never be exactly the same and they won't match the same requirements and goals from a user's perspective and from developers point of view. Don't think of wheels, but of tires. There are a lot of different sorts of car tires nowaday because they all suit a particular need. Every winter in France we change the tires on my dad's car to put snow tires. Why don't we complain about that and demand good tires for both steep and snowy roads as well as dry and hot freeways? Because that's not what you really want, you want a set of tires very good at one thing instead of clumsy at many purpose.

The problem with developing API's that rely on some third party project is that if the third party project decides to grow in a different direction, or modify components or APIs in a way that doess't harmonize with your own APIs, you end up having a huge mess. You end up having to fork their project (assuming that their project has a license compatible with your own). Even if they are doing fine but you have bugfixes/feature requests that go unanswered, you have to fork the project. Or when their release schedule is incompatible with your own, you end up delaying your own product or forking theirs.

This problem doesn't usually occur as an application developer, or even developing massive APIs that are internal to an organization, but happens when you are developing APIs for the general community. Also, it cannot be forgotten that portions of SwingLabs are candidates for inclusion in future versions of the JDK. As such, we need to a) have proper copyright ownership so that Sun can change the license to the standard java license and b) rewrite anything that is from a third party project anyway before it could be included in the JDK (unless we got the rights to all of their source code and liked it. Either way, it''s going to be a fork).

I can say this much, we are very interested in providing developers the best solutions possible for writing rich client apps. We're not interested in having our own personal implementation "win" (assuming there was such a thing), but rather in having the entire community win. Part of this will require many judgement calls, and where the SwingLabs team's judgement differs from another team's judgement, we'll get differences. Since SwingLabs is LGPL, there's a lot of safety in using SwingLabs -- there is no vendor lock in. And, those portions of SwingLabs that we want to move into the JDK may be part of a formal JSR as well, so everyone has a chance to have their voice heard.

Hopefully this helps present some of the trickier issues involved in using third party components/libraries, the forces and factors at work on us, and express our desire to work with the community to provide the best solution in one place, and in a way that may be accessible to all of the java community in the future.

My personal opinion is that sometimes you're better off using existing code, sometimes you're better off buying existing code, and sometimes you're better off writing your own. Which is best for a given situation is a judgement call. And hey, let's ease up a bit on the "Not Invented Here" accusations.*

[*] While this blog was inspired by zander's use of this phrase in my last blog's comments, it is in no way intended as a rebuttle or slight. Sometimes this accusation is a worthy one, and I cannot comment on whether his use of it was accurate or not. This question has been posed to me several times over the last year, so I thought now was a good time to post my opinion.

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!

SwingLabs - Direction and Status

Around June of last year I first became aquainted with the JDNC project. As a professional Swing application developer, I was very interested in an open source project that would make my job easier. It was clear to me that JDNC was positioned at the right time to make a huge impact on rich client application development.

Swing is an excellent UI toolkit. It provides clean abstractions between the model for a UI component, the component, and it's painting code. In my years of working with Swing (and writing a few app frameworks and component heirarchies in the process) I was mostly satisfied. Yet there were a few things missing from the standard toolkit that I felt were really important, and that most of us writing Swing apps have implemented independently.

For example, in forms based database applications a "date chooser" component is a must have. Yet, there wasn't a default date chooser in the Swing toolkit. Other examples of often implemented features include sortable tables, saving component size/state to preferences, login dialogs, progress dialogs, error handling, action frameworks, row highlighting in JTables and JLists, and default renderers for currency, decimal, and other data types.

The JDNC project was initiated to do two things; first, to make writing Swing applications easier. Also, rather than having to wait 18 months to 2 years for new functionality to be rolled into the JDK, JDNC allows developers to get their hands on tomorrows technology today. Second, the JDNC project was established so Swing developers could prototype features, components, and prospective API's before actually incorporating them into the JDK. This provides the Swing team with much quicker and more applicable real world feedback, and has proved invaluable.

For all these reasons I was drawn into JDNC. Since having joined Sun in November of 2005, I'm now the SwingLabs team lead. The rest of the team is composed of a very talented and intelligent group of people from around the world, both within and without Sun. Together we are working towards a 1.0 release of the SwingLabs projects (which include JDNC).

I want to give a brief description of the current status of the project, where we are headed as a team, and how you can help us create a library so useful that you would recommend it to your collegues.

Earlier this year JDNC was subdivided into three different projects. These were DataBinding, SwingX, and JDNC. A single parent project, SwingLabs was also created. SwingLabs is intended to operate in a manner similar to the GNOME project. Just like GNOME, SwingLabs is really the sum of it's parts, not a true project on it's own. It serves as a single point of entry into a host of related sub projects.

At this moment, we are working hard to make the APIs in the SwingLabs projects (notably SwingX, DataBinding and JDNC) stable. We realize how important it is for developers to have a stable API base to work with. I wish I could say that we were finished making incompatible changes to the source code, but we aren't quite there yet. What I can say is that 80%-90% of the code base is stable. The majority of the flux is in the databinding APIs, particularly the binding packages. In a future set of articles I'll discuss the details of the binding framework.

The SwingLabs developers have done an awesome job working on demos and fixing bugs in the SwingX code base. The UI components are really looking good. There are some excellent components and code in the incubator as well.

I believe the biggest need we have in the project right now is better documentation and presentation. We have aquired the swinglabs.org domain which will soon host our "user" website. The java.net web pages will continue being used as the main development pages (meaning, advanced developer information will still be located on java.net), but http://www.swinglabs.org will be designed for individuals who are interested in getting the latest jars, but not in hacking on the sources themselves.

Second, there are three levels of documentation that need to be addressed within the projects, listed in order of importance:

1. HowTo's, tutorials, code snippets, tips & tricks, etc
2. JavaDoc
3. High level "whitepaper" documentation

Finally, we are working closely with the NetBeans team (and all other IDE's are invited too!) to ensure that our components are toolable and comply with the JavaBeans specification. Tool support is a very important driver for the SwingLabs projects.

In summary, SwingLabs aims to provide a suite of components and technologies that will simplify data oriented application development in Swing. We're getting close to a 1.0 release (the exact date will be announced Friday, Aug 19th). We are working to provide better and more clear documentation, examples, tutorials, and a more pleasant user experience. We welcome help and advise!

This work is licensed under a Creative Commons License.