Modifying a JList through its Model

Imagine a small program that builds a list of ice cream flavors, displays them in a JList, and then adds one more flavor while the window is open. The new flavor appears on screen. The natural question is what, exactly, was changed in the program to make that happen. Before reading any theory, try to answer that question yourself. The answer determines how you will debug list problems in Swing for the rest of your work.

A JList is best understood as several cooperating parts rather than one object. The list that appears in the window is only the view. Listener objects act as the controller, responding when the user clicks an item. The data itself is held by a third part, the model. The source names this object a ListModel, and it is the object that actually knows the list of items.

The practical consequence is that the list you see is not where the data lives. If you want the list to show something different, the object to change is the model. Changing the JList directly is not the mechanism the source describes for adding or removing flavors.

This means choosing a model involves two decisions at once: what the model holds, and what you are allowed to do with it. Two lists that display the same items can behave very differently because their models offer different operations. When a list does not behave the way you expect, the first thing to check is which model class you are actually working with.

When a JList is constructed directly from an array of objects, Swing creates a model for you. That model is deliberately simple. It can report how many items it contains and what those items are, and that is essentially all it can do. The source is explicit that there is no way to add items to this list or delete items from it. If your program needs that capability, you must use a different list model.

The model created from an array is not a DefaultListModel. This matters because the methods you can call depend on the actual class of the model, not on the fact that it belongs to a JList. DefaultListModel is a parameterized list model that supports adding and removing items, and it is the model to use for a modifiable list.

The flavor program holds the DefaultListModel in a variable that is kept for the life of the program, rather than only inside the constructor call. This matters because a reference to the model is what lets you change the list later. If the model were created and passed straight into the JList constructor with no variable kept, you would have no handle to call add or remove methods on while the program runs.

The mechanism behind the automatic update is an event. When a list model is modified, it generates an event of type ListDataEvent. The JList registers itself with its model as a listener for these events. When an event arrives, the JList responds by redrawing itself to reflect the new contents of the model.

The important consequence is that the programmer's only responsibility is the change to the model. No separate step is needed to repaint the list. This is why a bug where the screen is stale usually points to a broken link in the chain of model, event, and view rather than a missing repaint call.

Once items are removed from the model, the positions of the remaining items change. Suppose the model holds three flavors, and you remove the item at index 1. The item that was at index 2 moves into index 1, and the remaining items are renumbered from the front. Tracing this shift is often the difference between a list that looks right and one that appears to show the wrong item.

When the visible list does not match what you expected, work backward through the chain of model, event, and view, and ask at which step the result diverged. Start with the screen and move back: Did the JList redraw? Did it receive a ListDataEvent? Did the model change? Did the change happen on the model object the JList is actually using?