Annotations Useful. Really?

We have started taking advantage of Annotations (introduced in Java 1.5) all over application and especially in  Hibernate.  Initially, I was happy to get rid of those hbm files and bringing in Named Queries inside Java classes. This is how a table definition and a named query goes,

@NamedQueries( {

@NamedQuery(name = “selectValues”, query = “select count(*) from XXX xxx”) })

@Table(name = “XXX”, uniqueConstraints = @UniqueConstraint(columnNames = “XXX_ID”))

This is indeed convenient compared to having a separate hbm file to define the table and class mapping. Also, it makes more sense to have the query inside the class than writing it in some DAO class or a property file.

But, when the application started evolving, we had to make several changes to these classes. Say, if the table name changes, we should change them in this class or want to make a small change to the query, we should change them in this class. That’s when I started realizing that, refactoring a class and building again is more time consuming than making those changes in the property XML files.

So, ideally these configurations should have been existing inside an XML file. Though Annotations makes it more readable, along with it comes the headache of refactoring and rebuilding. So, when you think of Annotations next time, keep this in mind.

Here is what a Java guru has to say about Annotations,

In his case against annotations, he says that annotations are not metaData but just decorative data. Annotations are hard coded configurations that cannot replace XML. He feels that Java annotations were just meant as a response to .NET and not something that Java developers want.

Swing Combo Box Selection Issue

Java has many esoteric features. This is one such thing (Apparently so). Recently, I had a requirement to place two combo box in a UI and at any time during execution, the selection of those combo boxes should be synchronized. (If item 1 is selected in combo 1, item 1 must be selected automatically in combo 2, item 2 combo 1 to item 2 in combo 2 and so on). Here is the code snippet,

String labels1[] = { "A", "B", "C", "D","E"};
String labels2[] = { "A", "B", "C", "D","E"};
comboBox1 = new JComboBox(labels1);
comboBox2 = new JComboBox(labels2);
comboBox1.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0)
{comboBox2.setSelectedIndex(comboBox1.getSelectedIndex());
}
});
comboBox2.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0)
{ comboBox1.setSelectedIndex(comboBox2.getSelectedIndex());
}
});

This piece of code is straight forward and works as expected. However, if the labels1 is changed to the following,

String labels1[] = { “A”, “A”, “C”, “D”,”E”};

When the second “A” is selected in the first combo box, corresponding “B” is not selected in the second combo box, instead “A” is selected.

Reason: According to the documentation of getSelectedIndex(), it returns the index of the first item that matches selection. Since it uses equals() method to match the items, it just does the String equals() comparison of the items and returns the first “A”.  There are few solutions to overcome this issue. Here is one.

MyItem a = new MyItem("A");

MyItem a1 = new MyItem("A");

Object labels1[] = { a, a1, "C", "D","E"};
class MyItem{
    String s;
    public MyItem(String s){
        this.s = s;
    }

    public String toString(){
        return s;
    }
}

Though, objects a and a1 are same String, they are Objects of class MyItem. Hence, the ordinary String class equals() will not apply here. And the problem is gone!

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!