New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Will dynamic languages save Swing?
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:
- 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.
RelatedVendorContent
18 agile and lean practices for effective software development governance
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
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
-
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/.
8 comments
Watch Thread Reply