| Swing | Custom |
| javax.swing.JButton | com.xxxxx.XButton |
| javax.swing.JCheckBox | com.xxxxx.XCheckBox |
| javax.swing.JComboBox | com.xxxxx.XComboBox |
| ... | ... |
In the preceeding table you would of course replace xxxx in the package with an appropriate company name and change the X to an appropriate letter
Now you might be thinking, what would be the point of doing this. The point is that by forcing all developers to use the com.xxxx swing classes instead of the swing classes directly, you give yourself a lot of leverage in being able easily change application behavior at a single point.
How often have you been developing an application, added a neat feature to some Swing widget and then said "Gee, I wish I could add this to the rest of the application". In order to do so you would have to troll through the application manually changing J references to your component reference.
By forcing all developers to use the xxx components, these sort of changes can be made instaneously. Additionally, bug fixes to problems in the existing swing classes can also be applied instanteously. For example, we had a problem with the JMenuItem not accepting a shortcut correctly. We fixed this in or custom descendant, WMenuItem, and any developer using the WMenuItem got this fix seamlessly.
When creating descendants from the swing classes, overriding the constructors can be a bit tricky. The reason is that you want to leave yourself a central point to place initialization code but you can never be 100% certain how the constructors may be chained together. To handle this, we adopted the approach of overriding each constructor one by one and called our initialization function after calling the appropriate inherited constructor. Below is an example of a JLabel being overriden to a GLabel.
|

