fibrillation : Java Glossary
In the 1950s, Walt Disney set up a room full of moustraps and on each were balanced two ping pong balls. He
tossed a ball into the room, and a fission explosion ensued, with each ball triggering another pair of balls to
fly into the air.
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.
I have put in an RFE (Request For Enhancement) to Sun asking them to provide ways to set components while temporarily inhibiting the
triggering of new change events.
- 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 JVMs (Java Virtual Machines)
seem to behave slightly differently in this regard.
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.
A somewhat slower, but equally irritating fibrillation occurs when a website issues an HTTP (Hypertext Transfer Protocol) 303 permanent redirect from URL (Uniform Resource Locator) A to B, and simultaneously
one from B to A. If you correct your website links daily, each day to must toggle between A and B.
Even more pathological is a single redirect chain that goes in an endless loop.