fibrillation : Java Glossary

This is simpilar to what happens if you are not careful about Events triggering other Events in Java.

Sometimes, in your ChangeListener you change the value of the component that caused the event. This in turn triggers yet another ChangeEvent. Your app goes into an endless loop fibrillation. You will also get into this problem with Applet instances intercommunicating changes on a page.

• One way to avoid this problem is never to set a Component’s value programmatically without first checking if you really need to. Don’t set unless the value has actually changed. Components don’t do this for themselves. Any set is treated as a change even if you are setting to the same value. You still get unwanted ChangeEvents, but they don’t propagate.
• The problem is more difficult to nail than you might first think. Events can sit in queue delayed for a while, which can often defeat simple boolean variable schemes.
• A reasonably robust scheme is to have the listener check to see if anything has really changed, and, if not, just return, without propagating the change trigger on in any way.
• You also have to be careful with any sort of toggle. If you expect an event to turn the toggle on or off, that event might arrive too early, too late, or get lost altogether. I have found that different browsers and different JVM (Java Virtual Machine)s seem to behave slightly differently in this regard.
• JCheckBox.setSelectedItem will trigger an ActionEvent that is immediately dispatched, even before your event handler completes. This is almost never what you want. You usually need to create some mechanism to ignore the event. Otherwise you can get a fibrillation where events trigger more events in an uncontrolled way.