Geertjan is a DZone Zone Leader and has posted 457 posts at DZone. You can read more from them at their website. View Full User Profile

How to Choose a Java Desktop Framework

08.27.2008
| 29519 views |
  • submit to reddit
Unlike web frameworks, Java desktop frameworks are not a dime a dozen. There are, to be exact, four—Eclipse RCP, Swing Application Framework (i.e., JSR-296), NetBeans Platform, and Spring RCP.

Discussions all over the place attest that each of these frameworks is different enough that transferring from one to the other is not a painless process. Therefore making the right choice up front is pretty important. Assuming you've arrived at the point where you're spending more time working on your in house framework than on the application/s built on top of it, it's time to look around for one of the existing frameworks to handle your infrastructural concerns. In the web world, no serious application works with plain old JSPs and servlets—instead, the developer/s choose a framework as the basis of their application, since it provides the underlying requirements common to all web applications. So it is too, increasingly, in the Java desktop space, where the developer seldom has the time, interest, and/or skillset to develop an application's "plumbing"—lifecycle management, docking framework, actions system, etc. But which specific framework to choose? By means of which criteria?

So, without further ado, here are what are, in my personal opinion, the most important criteria to consider. I'd be interested to hear others and then we can perhaps pick up each of the existing desktop frameworks and see how they stack up.

  • Architecture. How scaleable is it? I.e., can it be extended from the outside, via plugins? Is it based on generally accepted standards? E.g., Swing is the standard UI Toolkit; OSGi is the standard bundle format. On the other hand, do "generally accepted standards" matter to you? And does it matter if the application can't be extended? How well can existing frameworks integrate into the framework? E.g., if the framework offers a windowing system, is it possible to swap in a different windowing system offered by competing vendors? Or are you locked into all of the framework's native features? How modern is the architecture? E.g., is there a strong reliance on XML or is it possible to use annotations instead? How flexible is the architecture for these kind of modifications?

  • Feature Set. Are the features very extensive or only very basic? How much of a very large application's boilerplate code and typical "plumbing" can you let the framework handle for you? Does the framework provide you with little more than an action system? Or is there also a windowing system? And how well does it play with others? And how extendable is it? Can it, in fact, be extended and, if so, how easily and how well supported is it to do so? If you were to write down all the things that you'd like your perfect framework to have, which of the existing frameworks matches your needs?

  • Open Source. Is it open source? Does it matter? What are the pros and cons when it comes to your specific needs? Are the fears you, or someone else, might have in relation to open source in this context balanced out by other factors?

  • Community. Is it large? If it is large, who does it consist of—lots of one-person developers or large companies with distributed developers working on the same project? If it is small, is it growing? If it is small, are there good reasons? Is the community passionate? Are there few/many examples of the framework being used "for real"? A long list of screenshots? Testimonials? Blurbs on various websites attesting to the wonderfulness of the framework underpinning their app? Or are they too embarrassed to mention it?

  • Learning Curve. How hard is it to get started? If it is hard, are there good reasons, such as the complexity of the framework? In that case, is the complexity justified or is it an early warning sign of a badly designed framework? If the learning curve is long, is the end point worth reaching? If the learning curve is small, could that be because the framework doesn't have much to offer? If the learning curve is long, is that because the architecture has introduced many new concepts that are known in other forms elsewhere, instead of simply using the standard approaches? Does it rely very heavily on existing approaches elsewhere, thus making the learning curve pleasantly short? Does the framework offer a training course?

  • Tooling. What kind of tools are there for the framework? Do the major IDE's support it? Or maybe it is so good that there are very few specific artifacts requiring special support? How much can be generated/automated? What are the specific pain points where tooling is needed and could those pain points be solved without tooling, i.e., by implementing the framework in a different way?

  • Documentation. Is it reliable? Up to date? Are there contributions from the comunity? Does it cover the absolute basics? Does it also cover all the advanced topics that the framework concerns itself with? How many unexpectedly undocumented "gotchas" does one typicaly come across? Are there recently published books about the framework? (That's a good sign because it means that the framework lasted at least as long as the time it took for the book to be written and published.) How many books? How up to date? Only in English? Have they been translated? If not translated, is there interest in doing so?

  • Support. Considering the documentation and the community, as well as anything else the framework might offer (mailing lists, helpdesk), how quickly/efficiently can your problems be solved when you have them? If you were to have a deadline tomorrow with a big problem today, which framework's support would be the one you could most rely on to help you out? Do the mailing lists have, on balance, more complainers than helpful people? How responsive are the core contributors to the framework to questions that are asked by newbies? How quickly and thoroughly are bug reports handled? Are there patches or do you have to wait for the next release when you encounter a bug? Can bugs be escalated and under which circumstances?

  • Future. What's the framework's future? Is there a company behind it that is invested heavily in it? How does it communicate with its users about its future, if at all? What's the framework's past been like? E.g., has it dropped out of the air without any explanation and has it suddenly reappeared on the scene without much of a plan going forward? Has it existed consistently and has it shown solid progress over its lifetime? If it were a piece of ice in the middle of a lake, would you feel safe jumping on it?

I suppose many of these criteria could apply to anything. However, here I'm trying to provide someone evaluating desktop frameworks with some criteria that they might have overlooked while shopping for a solution that could, potentially, have a very big impact on the success of their project. Interested to know which of these spark debate and also to see whether there are others that should be added!

 

AttachmentSize
confused-guy.jpeg4.94 KB
Published at DZone with permission of its author, Geertjan Wielenga.

Comments

David Lin replied on Wed, 2008/08/27 - 11:25am

Nice article. There is one more desktop framework form JIDE, which comes with a full-set of features as well and supports concepts like application lifecycle, resource injection, etc. Similar to any other framework does.

David

Deren Ebdon replied on Wed, 2008/08/27 - 3:34pm

You might also consider http://www.jgoodies.com/.

Luan O'carroll replied on Thu, 2008/08/28 - 7:43am

"Unlike web frameworks, Java desktop frameworks are not a dime a dozen. There are, to be exact, four"

That's sort of funny - I would have said the opposite, that there are lots of desktop frameworks :-o And even odder that you omit Sun's great new technology, JavaFX. Isn't that aimed at the desktop?

Judging by some of your metrics (e.g. books) then Eclipse RCP is probably the only framework to choose, but that seems like taking a sledgehammer to crack a nut for some 'desktop' applications. I guess it comes down to your notion of what a desktop application is, even the distinction of web vs desktop is somewhat artifical these days.

In any case these 'desktop frameworks' are only part of what is needed for many applications and none may give a perfect fit, so I would suggest that another major concern should be how easy it is to replace one such framework with another and what impact the choice of frameworks has on how you code/build/assemble your application.

 

 

 

Geertjan Wielenga replied on Thu, 2008/08/28 - 8:58am in response to: Luan O'carroll

[quote=luano]

"Unlike web frameworks, Java desktop frameworks are not a dime a dozen. There are, to be exact, four"

That's sort of funny - I would have said the opposite, that there are lots of desktop frameworks :-o And even odder that you omit Sun's great new technology, JavaFX. Isn't that aimed at the desktop?

[/quote]

Not in the sense that the frameworks listed here are frameworks -- e.g., no window framework provided by Java FX. On the other hand, I take your point -- desktop frameworks can encapsulate many things.

[quote=luano]

Judging by some of your metrics (e.g. books) then Eclipse RCP is probably the only framework to choose,

[/quote]

Pretty sure that there are also books on the NetBeans Platform. In fact, I wrote parts of one of them myself.

[quote=luano] 

but that seems like taking a sledgehammer to crack a nut for some 'desktop' applications. I guess it comes down to your notion of what a desktop application is, even the distinction of web vs desktop is somewhat artifical these days.

[/quote]

Sure.

[quote=luano]

In any case these 'desktop frameworks' are only part of what is needed for many applications and none may give a perfect fit, so I would suggest that another major concern should be how easy it is to replace one such framework with another and what impact the choice of frameworks has on how you code/build/assemble your application.

[/quote]

Definitely. I don't remember claiming that these desktop frameworks provide everything you would ever need.

Geertjan Wielenga replied on Thu, 2008/08/28 - 9:22am

I guess I should have been more explicit in my terms. By "desktop framework" I mean those frameworks that provide a skeleton application on top of which the programmer develops their own functionality. So, I agree JIDE and JGoodies are applicable. However, JavaFX isn't.

JeffS replied on Thu, 2008/08/28 - 12:23pm

Based on your criteria, I think it boils down to two:

 Eclipse RCP

... and ...

Netbeans Platform

 

Both have excellent books and docs.  Both have large communities.   Both have corporate support.  Both are open source.  Both have proven track records.  Both have great tooling support (Eclipse and Netbeans themselves).  Both give a great foundation for producing powerful, performant, GUI application.  

 And with both, unless I'm producing a small, trivial app, I'd use them over straight SWT or Swing.

 Swing application framework seems to be on hold at the moment, as I heard that the main developer left Sun.

Spring RCP I don't know enough about to comment.  But I haven't seen any books on it, I don't see much of a buzz or community behind it (Spring is mostly popular on the server side as a replacement/compliment to JEE).

Harald Krake replied on Fri, 2008/08/29 - 6:28am

Agreed on all those mostly technical criteria, but what about productivity? ;)

 

Geertjan Wielenga replied on Fri, 2008/08/29 - 6:38am in response to: Harald Krake

[quote=hk18689]

Agreed on all those mostly technical criteria, but what about productivity? ;)

[/quote]

 

Sure, but how do you define that in this context?

Kevin Adams replied on Fri, 2008/08/29 - 7:27am

It's always amazing to me when I read a great article like this, only to see it followed up with a bunch of comments containing "corrections" from the neckbeards. Seriously people, do you ALWAYS need to feel smarter than the author?!? I guess they need the validation. Get over yourselves!

Great article Geertjan! This article is exactly what I've been looking for in choosing a desktop framework.

Harald Krake replied on Fri, 2008/08/29 - 11:04am in response to: Geertjan Wielenga

Geertjan,

sorry for my short comment. I'll try to explain:

I think there are two categories of frameworks.

Most of them fall into the first category and are focusing on a certain problem domain or a set of such domains. For example IoC, persistence, plugin/module management, window docking, GUI (forms, validation, data binding), and alike. They are designed with a bottom-up perspective in mind: "Here I am, _the_ generic solution for the blah-problem. All projects facing blah should use me!". The criteria you mentioned above apply to this category of frameworks.

The second category is focusing on a certain type of application. Those frameworks address almost all problem domains such applications typically deal with, but they are less generic in what they do and they are based on assumptions, conventions, restrictions and are usually highly intrusive. However, if the requirements of the project/application match those addressed by the framework, you get an unbeatable productivity. Grails is an example, or looking beyond the rim of the teacup, there's Rails (ok, both are web, not desktop).

Stakeholders usually don't care whether the persistence layer can by exchanged just by editing an XML file. They care about time and money (and about quality -- if you're lucky). Productivity-oriented frameworks fail in many technical aspects you mentioned, but given the requirements of the particular project, the skills of your team and other constraints, the question "how does framework X improve productivity?" can help to change opinions.

Harald

Venu Gopal replied on Mon, 2011/08/29 - 12:54pm

Hi everybody, iam very happy to be here Thanks Venu

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.