Tracking change and innovation in the enterprise software development community
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Defy all
Challenges.
Microsoft®
Visual Studio
2008
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Posted by Rob Thornton on Feb 23, 2007 08:00 AM
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:
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.
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
The Agile Business Analyst: Skills and Techniques needed for Agile
Evolutionary Design through Agile Development Podcast
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
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.
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.
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
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.
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
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 ;)
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/.
Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.
Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.
Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.
Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).
Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.
Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.
In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.
In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.
8 comments
Reply