Simplifying a Swing Application for Dolphin
By dannycoward on May 26, 2006
You heard about the two new Swing JSRs, each of which aim to make developing Swing applications easier, right ?
The Beans Binding JSR promises to simplify that large chunk of your Swing application concerned with hooking up a GUI component to the data it represents. This code is always concerned with keeping the data and the GUI in sync ("do I really have that little money in my checking account ?"), and usually its doing type conversion ("uh, my paycheck is in dollars, not pennies thankyou very much") and validation ("Error, you have entered an amount exceeding your current balance. Please rethink your plan to chuck it all in and sail round the world") as well. Scott's blog has much more on this new work.
Hans' Swing Application Framework JSR is aiming to provide standard API support for some of those chunks of code that keep popping their heads up in most all Swing applications, you know, the part that manages user preferences, or that remembers application specific state across sessions, or that preps things like databases on startup and cleans such things up on exit.
Ease of development has been a big deal for Java EE. In case you had your head in the sand, Java EE 5 is done, blossoming with a newly revamped programming model which focuses on ease of development. (Check out the before and afters from JavaOne - slides). There are of course as many opinions on ease of development as there are working styles. And working style can be a fraught area for us developers. We have on occasion been known to lose our cool in discussions thereof, particularly when personal styles become a public matter. When engaged (or occasionally enraged) in the activity of developing an application or system, our process is often very interior, solitary and introverted. While what we produce at the end can be a thing of functional or even aesthetic beauty, comparatively little of the process by which we got there remains. Were we sculptors, the floors of our studios would be waist deep with scrapings, chippings and discarded previous efforts. Were we musicians, we might laugh up our sleeves at us developers who think that 'doing our thing' in pairs is an extreme measure, or puzzle at the idea of an orchestra of soloists.
My only point being that ease of development is often an electric issue. However it appears that the main activities of development: learning, prototyping, designing, developing, enhancing and maintaining, benefit a majority of developers when they are kept brief and simple. That happens best when technology takes on some of the load, respectful of our attachment to style, for us.
I have high hopes these new JSRs will take some of the load of developing Swing applications for Java SE 7 'Dolphin', making the applications themselves shorter and simpler. And in a style that I hope will work for most everyone, not least because Scott and Hans will be joined in these efforts by some really expert luminaries of the Swing community.
That should ease development.