Does Swing need RAD?
Jun 7th, 2005 by matt
The fact is, Swing is not a “newbie-friendly” library. In fact once you become intimate with Swing you still may find it tedious to work with. Other well-known languages such as VB, Delphi, and C/C++ often have RAD builders that have greatly simplified development of user interfaces and - to give credit - have aided in the construction of some excellent software that might not have been built in their absence.
The RAD builders of some other languages are a tribute to the complexity of their respective language or library (Motif, anyone?). Swing - for all it’s perceived complexity - is rather simple to use once you understand it’s foundation and intent. Now, purists and their couterparts alike may argue that the details should be irrelevant and the API should just work. I certainly agree. I’m sure most would also agree that a coffee cup works best when kept right-side-up but you would probably only know that by knowing the world in which it exists.
Both the community and commercial support for Java these days is overwhelming. Many vendors and IDE’s are providing better support for RAD Swing development. I’ve seen demos of the next NetBeans builder and it’s pretty impressive. The main benefit of the builders is the reduced time to develop (and maintain) a simple interface. Especially dialogs and other sets of components that are usually nothing more than Composite implementations. The drawback is that they typically are of little use when the requirements get too complex and dynamic.
Knowing the foundation and intent are key to being successful with Swing whether you use a builder or not. The foundation of Swing relies upon MVC and every Swing developer should understand the consequences of that (both good and bad!). The intents of Swing, in short, are flexibility, pluggability, and extensibility. The Swing API is quite empowering because it has really enabled the developer to be creative yet maintain an elegant interaction with the API around. A RAD tool won’t always be able to bridge the inevitable gap between the API and your unique solution.
