Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted 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:
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.
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Innovation in Your Data Centre
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
Agile Development: A Manager's Roadmap for Success
Architectures Behind Facebook, Skype, Sky.com, Bwin, League of Legends @ QConLondon
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/.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
8 comments
Watch Thread Reply