Falling From A Swing

Before my last assignment, for sometime I had hoped to work on an a Swing App as a short break from developing web UI’s and to see how the other side lives. (Just like Simon does it seems)

Well my first experience has left me fairly jaded, mostly because Swing was far more complex than I expected – certainly far more complex than it should be. Perhaps Swing is another example of overtly complex software development in Java.

The most significant gripe I have with Swing is its tool and framework support. They don’t seem to be there yet, at least to the same quality and depth of web tools and frameworks. I guess its a reflection of the volume of Swing vs. Web App implementations. There are plenty of tools to assisting in composing Swing screens, but there’s always a catch. The code generated is terrible (sound familiar?), they require a custom component library, they come at significant cost. There have been no frameworks like a Struts that has strongly influenced Swing application development.

Some (non-coders) I worked with were of the opinion that Swing Apps must be simpler to develop than Web Apps. There’s less tiers right (as in physical tiers)? Yes, but I believe it’s actually harder. Yes, less phyiscal tiers may mean simpler installation and configuration, but as a software developer that doesn’t help my day-to-day activities. From a software perspective the same tiers exist - but Swing offers developers even more opportunities to hack. For instance, as the View is completely Java it offers more opportunity for the View to be spaghettized. Also a significant amount of ‘glue’ code is required to enable drag-and-drop, copy and paste, undo and redo functionality and alike. Glue that can be quite easily hacked to hold domain logic and other layers. So it requires plenty of discipline to maintain the conceptual integrity of Swing Apps, even more than Web Apps.

Talking of Swing Hacks, I recently purchased a book titled just that, Swing Hacks, containing 100 ‘hacks’ for constructing complex Swing UI’s. For mind, right now that title makes perfect sense for Swing.

Swing tries to provide you with the tools you need out the box, like progress bars, file choosers and transfer handlers, but they often require implementation or customization. This slows your progress and constantly gets you asking yourself, ‘It feels like I’m re-inventing the wheel here. Surely this type of thing has been done before? How could it possibly be this verbose?’.

Going even deeper, occasionally Swing’s API made checkstyle compliance extremely difficult. In cases were the API presented methods that contained some 8 or so parameters, the team had no alternative but to crank out a suppressions file. Data Abstraction Coupling was another that the UI layer consistently struggled with, after all it’s fairly common for containers to house a fair amount of components.

Then there’s the functional testing tools, there are plenty of them but each have their short-comings. Mind you, we were using open source tools (eventually choosing Jemmy) so you get what you paid for, but plenty of customizations were required. Screen discovery as Pam mentioned in her blog was one of them. We encountered larger issues striving to have our functional tests executed on both Windows and Macs, but we never expected that to be a simple task. Different key-strokes and different component behavior all mounted to tests that were time-consuming to produce, so much so that some journeyed to manual testing land (mysteriously never to be discussed again). The functional tests were also extremely fragile, for instance drag-and-drop tests needed to literally control the mouse, so no mutli-tasking for developers while tests executed. Regardless of these set-backs, the value of immediate test feedback is too great for any team to justify scrapping them.

I admit that working with a Swing team that was relatively inexperienced compared to the Web teams I’ve worked with has significantly influenced my thoughts. Still, Swing is screaming for simplification. I understand that Mustang will re-write/enhance some of Swing. I particularly applaud the decision to Improve Swings drag-and-drop Support. Great - it’s all much needed, but don’t stop there. In the short term, Swing is crying out for some simplifying frameworks, just as Web Apps were 5 years ago.