Home/ Questions/Q 651123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T22:07:42+00:00

I was wondering if the following is common for regular Java applications when receiving

  • 0

I was wondering if the following is common for “regular” Java applications when receiving callback/events. Those callbacks may be triggered by user input but also by other means so it is not only related to UI events:

public void handleEvent( @NotNull final SomeEvent e ) {
    final boolean process;
    synchronized ( this ) {
        process = !e.equals(filter);
        filter = e;
    }
    if ( process ) {
        ...   
    }
}

Basically under some complicated scheme (very complex UI involving several views of a same model and where the user can modify the model from different screens [like in complex 3D programs]) I’ve got lots of events firing and I’ve noticed that I could filter out duplicate events using the above snippet. If an event has been processed and the next event to come is exactly identical to the last processed event (saved in the filter reference), then the event/callback is simply ignored.

It works fine. I was wondering if filtering out duplicate events was a common technique?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Not always, but usually this can be a sign that some elements of the event cascade chain aren’t properly detecting that they don’t need to send an event. The classic illustration is a bean setter that generates a PropertyChangeEvent even when the value hasn’t changed.

    While what you’ve done will filter these events out, it doesn’t address what may be a fundamental underlying issue.

    The problem is that these “errors” can combine to form infinite loops. Extending the bean example above, say you have a UI that resets its editable value based on that bean field… and resetting the UI value will also call the bean setter because proper dupe checking wasn’t done there either. The first time the value is edited and endless loop will occur.

    These examples are obvious when they happen but as notification hierarchies get more complicated it becomes harder to track these things down and they potentially occur at more intermittent times.

    A good rule of thumb is to make every event generating component as conservative as possible. In the event (heh) you are receiving notifications from components that you can’t control, and will be forwarding your own events also then a filter like the one you’ve setup may be the only option to prevent the spread of a potentially larger problem than just performance.

    • 0