Will dynamic languages save Swing?

by Rob Thornton on Feb 23, 2007 |

Will dynamic languages save Swing? Does Swing need saving? These questions have been discussed in detail over the last few days with opinions varying from JRuby to Groovy as saving Swing to Swing not needing saving.

Julian Doherty started the discussion by stating that JRuby can save Swing. Building on 2003 post by Joshua Marinacci that listed the following reasons for Swing’s failure:

Swing apps are slow to build.
Swing layout managers suck.
Swing apps are hard to maintain.
Swing is too powerful.
No native features.
Swing apps have a bad history.

Doherty points out how dynamic languages, and Ruby in particular, can help resolve these issues. Responding to Doherty, pinderkent states that Swing is beyond saving due to performance and the build up of APIs that are not consistent with the evolution of the language.

Danno Ferrin jumps in rebutting some of pinderkent’s arguments and stating that Groovy is a good candidate to save Swing. He points out that Groovy’s closures will help developers avoid expensive computations on the Event Dispatch Thread. pinderkent maintains that Swing’s APIs make it unfixable.

Finally, Daniel argues that Swing doesn’t need saving. He goes back to Marinacci’s six points and disputes all of them. The discussion on his post goes on to debate the advantages of Groovy’s SwingBuilder (and similar libraries in JRuby) in speeding Swing development.

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Building Content-Driven Apps - Couchbase and Elasticsearch for Content and Metadata Stores

Faster PHP Through Java

Why NoSQL - Three Trends Disrupting the Database Status Quo

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

The problem is creating GUI in programming language by Cyril Gambis Posted

Re: The problem is creating GUI in programming language by Thom Nichols Posted

Re: The problem is creating GUI in programming language by Jonathan Allen Posted

Re: The problem is creating GUI in programming language by Ilya Sterin Posted

Re: The problem is creating GUI in programming language by ZedroS Schwartz Posted

Re: The problem is creating GUI in programming language by Ilya Sterin Posted

Re: The problem is creating GUI in programming language by ZedroS Schwartz Posted

You guys should try out F3 - Form Follows Function by Gopalan Suresh Raj Posted

The problem is creating GUI in programming language by Cyril Gambis

GUI is a very important part of any application (although usually underestimated).

Java and script language have been created to program algorithms, not to create GUI or to layout components. It's too bad that the GUI builders have never been able, for now, to generate code easy to maintain.
I have a dream someday, GUI won't be a programmer's task but a designer's task.

Cyril

Re: The problem is creating GUI in programming language by Thom Nichols

That's what's really nice about Groovy?s SwingBuilder and the like -- builders (the programming language concept, not the "visual IDE" concept) make the code much more closely represent the structure of the resulting GUI. And because of that it is very easy to understand and maintain. I imagine a designer could easily learn to use the Groovy SwingBuilder -- especially if they have a HTML/ JavaScript background.

That's why I feel sad about GWT -- while the technology is amazing, writing the GUI a la Swing feels like a step backwards. Someone was talking about a GWT plugin for Grails (which would be awesome) but I don't know how far it got.

Re: The problem is creating GUI in programming language by Jonathan Allen

I think trying to produce one-way generated code is a bad idea. The generated code, be it Java or raw Byte Code, should be out of sight and out of mind.

Once you start tinkering with generated code, you lose the ability to use the real source, in this case the GUI builder, to make changes.

When you do make changes, the original source and the generated code get out of sync and you introduce the question, "Which is the real version?"

One thing I found interesting was .NET's concept of partial classes. This allows users to manually extend a class with new methods, interfaces, and such while not touching the generated code.

Re: The problem is creating GUI in programming language by Ilya Sterin

I partly agree on the model where the gui building is completely seperated and though allowing that task to be performed by someone that specializes in UI layouts. I think the biggest issues with todays GUI toolkits like Swing and SWT is the programmatic initialization. I think interface design should be declarative, with hooks for modifying default behaviour, etc... There have been many attempts at that and it's becoming more prevelant. Look at Flex 2, XUL, Open Laszlo, etc... These are declarative GUI toolkits, that allow declarative data bindings, layouts, extensions, etc..., with hooks into customized code. This allows the business object model to be strictly seperated from presentation. Though this paradigm has been in use for many years, toolkits like Swing (although I love it's flexibility), don't force such seperation. Though I've had to maintain horrific code before that mixed business logic with interface layout/behavior.

Ilya

Re: The problem is creating GUI in programming language by ZedroS Schwartz

Hi Ilya

I've a different view on declarative programming. In fact, I've looked for almost an year for the "best web framework around".

And guess which one I took finally ? Wicket. Why ? Because of its "all Java code and Object Oriented design". With it, I can easily inherit part of my already coded GUI. All the presentation layer is, this way, really efficient to develop : I've some specific object suiting all my needs, and whenever they are some commun stuff I just do a parent class or an object I will reuse later. I don't have to fill in hips of XML files for the same component configuration each time.

From both a rapidity of development and ease of maintenance, I think it's great.

Re: The problem is creating GUI in programming language by Ilya Sterin

Zedro, it's great when you don't have to lay initial foundations. I think Swing is awesome. It's flexible enough to allow pretty much anything to be accomplished, and has great underlying pattern-based design, that allows your code to build on top of that. Now, that being said, there is a lot of work to be done to say initially setup your gui layout and its behavior. Also, the layout code generation tools out there, don't do a very good job in creating clean, maintainable code that fits into your design vs. having your design accommodate what the code generation tool produces. Declarative programming is one way of solving it. XML is not necessarily needed, though it's the most popular convention these days for some reason. One can also build a DSL for accomplishing such a think. Generating DSL code is a lot easier than generating general programming language code and though would allow some sort of a standardization in building GUI components. Right now, you're either stuck developing all by hand, or if you use some GUI builder tool, you're pretty much stuck with it for the duration of your product.

Ilya

Re: The problem is creating GUI in programming language by ZedroS Schwartz

As I said, I was referring more to Wicket than to Swing, which I don't know enough.

BTW, it's interesting to say as well that Wicket separates the page design from the rest, thus allowing even more flexibility than, in a way, Swing, especially for graphic designer.

As well, it may well be true that too much is to be done at startup before being efficient with Swing, I can't tell. What is certain, however, is that it's not the case with Wicket and that in this case it doesn't hurt at all ;)

You guys should try out F3 - Form Follows Function by Gopalan Suresh Raj

blogs.sun.com/chrisoliver/

F3 demonstrates that we're not exploiting the full capabilities of the Java platform for GUI development and that together with supporting tools like F3, the Java platform is highly competitive with or superior to competing GUI development platforms such as Macromedia Flash/Flex/Open Laszlo, Adobe Apollo, Microsoft WPF/XAML, Mozilla XUL, AJAX/DHMTL..

For more information, checkout Chris Oliver's blog at blogs.sun.com/chrisoliver/.