GWT dropdown Fail

A colleague has asked me to post some of my own failures here. For one, because he thought it’s unfair otherwise but for second, because he found a good one. It occured when writing a straight-forward GWT mockup of some GUI which finally was deployed a couple of weeks ago.

Here is the code to initialize a dropdown with some values:

   @Override
   public void onLoad()
   {
       templatesList.clear();
       GWTClient.getServerStub().getTemplateList(new AsyncCallback<List<Template>>()
       {
           
           @Override
           public void onFailure(Throwable caught)
           {
               
               GWT.log("", caught);
           }
           
           @Override
           public void onSuccess(List<Template> result)
           {
               for (Template template : result)
               {
                   // only use enabled templates
                   if (template.getEnabled())
                   {
                       templatesList.addItem(template.getName(), template.getId().toString());
                   }
               }
           }
       });
       templatesList.setEnabled(true);
   }

And here is the code executed on selection of an entry of that dropdown:

   public void onTemplateSelection()
   {
       selectButton.setVisible(false);
       templatesList.setVisible(false);
       templatesList.setEnabled(false);
       
       GWTClient.getServerStub().getTemplateList(new AsyncCallback<List<Template>>()
       {
           
           @Override
           public void onFailure(Throwable caught)
           {
               
               GWT.log("", caught);
           }
           
           @Override
           public void onSuccess(List<Template> result)
           {
               Template template = result.get(templatesList.getSelectedIndex());
               templatePanel.init(template);
               rootPanel.add(templatePanel);
               rootPanel.add(buttonBar);
           }
       });
       
   }

I guess I got lazy when I realized I had to cast the ID from String to Integer again in order to make it right. Bad choice. Probably the enabled-property came into that code later than the dropdown. Here you see what you get from laziness – your code stinks.

The code seemed to work quite fine until someone actually used the enabled-property on those templates. The dropdown still looked alright…

Naming Fail

I’ve no idea what went wrong here. Nice, clean code. Javadoc is present. Completely useless.

/**
* Interface for switchable artefacts
*/
public interface Switchable
{
        /**
        * set the component on or off
        */
        public void setOnOrOff(boolean value);
        
        /**
        * returns if the artefact is on or off
        */
        public boolean getOnOrOff();
}

More Enumeration Fail

I recently came across of some brilliant chunk of WTF-code. The reason was that some swedish users complained about the software not caring about their language settings.

First step was to review the method which stored the settings:

public class DBwriter extends DBaccess {

    public enum Lang {
	DE, EN, FR, NL, SV, IT;
    }

    public void saveLangSetting(long userId, Lang lang) {
	super.executePreparedStatement("INSERT INTO usersettings VALUES ('?','?')", userId,lang.name());
    }
}

Second step was the method which fetched the stored settings:

public class DBreader extends DBaccess {

    public enum Lang {
	DE, EN, FR, NL, ES, IT;
    }

    public Lang getUserLang(long userId) {

	Lang res = Lang.EN;
	try {
	    res = Lang.valueOf(super.executePreparedStatement("SELECT * from usersettings WHERE id=?", userId).getString("lang"));
	} catch (Exception e) {
	    // why should this happen?
	}
	return res;
    }
}

It was a famous moment to realize what was happening there. But it even got better in the moment I found the only usage of getUserLang:

Lang lang = reader.getUserLang(id);
session.setLanguage(lang.name());

I’m just proud the thousand monkeys on their thousand typewriters somehow managed to store some languages successfully.

Java Singelton fail

Exciting WTF moments at work (no joke, stuff I’ve seen coded by real Java professionals):

public static ThisObject getInstance(){
   return this.instance;
}

So far, so good. Looks like a normal singelton pattern.

public static void setInstance(ThisObject object){
    this.instance=object;
}

This seems to be a little odd. But ok, I’ve seen this before for smuggling Mock-Instances during jUnit-Test into the otherwise static-referenced Singleton. Not nice but quite applicable when Unit-Tests are created for code fragments using this singleton.

public static ThisObject createInstance(){
    return new ThisObject();
}

This code really caused some raising eyebrows. Turns out that someone reused some methods in a kind of stateless way, which where supposed to work only statefully within the instance of the singleton. So he created this little factory method which always created unused instances. This actually worked because no static fields were accessed within the methods.

public static void killInstance(){
    this.instance = null;
}

Code actually used with a lazyloading singleton pattern. Actually this was proven to be working code. Think about it. Twice.