This post originated from an RSS feed registered with Java Buzz
by Danno Ferrin.
Original Post: Swing and Groovy: Low-Carb Coding, not Syntactic Sugar
Feed Title: And They Shall Know Me By My Speling Errors
Feed URL: http://shemnon.com/speling/archives/cat_GUI.rdf
Feed Description: Danno Ferrin's Many Reasons he was a Comp Sci Major and not an English Major
Use Groovy and shed KLOCs over night. Sounds like some advert for the latest weight pill, but here is some empirical evidence. I was able to re-write the ButtonDemo.java section of the SwingSet2 demo that comes in your JDK distribution with about one third of the source code lines and one half of the total characters.
There are two principal contributors to this amazing weight loss* (YMMV of course). The first and IMHO nicest features is the use of closures. For those of you who either didn't major in Computer Science or suppressed the trauma of the sophomore year functional programming classes you may wonder what closures are. Closures are a very particular name for a very particular type of "first class function," or way to confuse the code segment and the data segment. They are very tight and concise, and most importantly can be assigned to specific event listeners in less than one line of code. And most importantly, Groovy closures look like simple java blocks.
Another feature allowing for the compression in size is the way the SwingBuilder handles JavaBeans properties. It looks like a constructor taking some sort of a python type dictionary as the arguments, but really the code that is generated is to call the default constructor and set the specific bean properties after the bean is constructed. It allows for readable compression of setting multiple properties in one line.
The demo is currently waiting to be added to Groovy itself as a sample, but here's a quick comparison of Groovy vs. Plain Java setting up the "Enabled" CheckBox on the right side of the demo to give you a taste.
checkBox(text:"Enabled", mnemonic:'E', selected:true,
toolTipText:"Click here to enable or disable the buttons.",
actionPerformed: { event |
btns.each { it.enabled = event->source->selected } } )
Groovy is 3 or 4 lines depending on what your end column is set to
JCheckBox enabled = new JCheckBox("Enabled");
enabled.setToolTipText("Click here to enable or disable the buttons.");
enabled.setSelected(true);
enabled.addItemListener(buttonDisplayListener);
enabled.setMnemonic('e');
// nearly 45 lines later in a different method and
// an anonymous nested class
public void itemStateChanged(ItemEvent e) {
JCheckBox cb = (JCheckBox) e.getSource();
if(cb.getText().equals("Enabled")) {
for(int i = 0; i < currentControls.size(); i++) {
c = (Component) currentControls.elementAt(i);
c.setEnabled(cb.isSelected());
c.invalidate();
}
// code for other buttons
Plain Java is 10+lines, not counting comments. Plus the code doing the checkbox action isn't interrupted by 40+ lines of other code. I am really starting to like Groovy alto and I am sorely tempted to actually use it in shipping code, but I plan on at least waiting until it is declared 1.0 soup and not beta.
Previous Topic
