Watching a variable for changes without polling

I'm using a framework called Processing which is basically a Java applet. It has the ability to do key events because Applet can. You can also roll your own callbacks of sorts into the parent. I'm not doing that right now and maybe that's the solution. For now, I'm looking for a more POJO solution. So I wrote some examples to illustrate my question.

Please ignore using key events on the command line (console). Certainly this would be a very clean solution but it's not possible on the command line and my actual app isn't a command line app. In fact, a key event would be a good solution for me but I'm trying to understand events and polling beyond just keyboard specific problems.

Both these examples flip a boolean. When the boolean flips, I want to fire something once. I could wrap the boolean in an Object so if the Object changes, I could fire an event too. I just don't want to poll with an if() statement unnecessarily.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

/*
 * Example of checking a variable for changes.
 * Uses dumb if() and polls continuously.
 */
public class NotAvoidingPolling {

    public static void main(String[] args) {

        boolean typedA = false;
        String input = "";

        System.out.println("Type 'a' please.");

        while (true) {
            InputStreamReader isr = new InputStreamReader(System.in);
            BufferedReader br = new BufferedReader(isr);

            try {
                input = br.readLine();
            } catch (IOException ioException) {
                System.out.println("IO Error.");
                System.exit(1);
            }

            // contrived state change logic
            if (input.equals("a")) {
                typedA = true;
            } else {
                typedA = false;
            }

            // problem: this is polling.
            if (typedA) System.out.println("Typed 'a'.");
        }
    }
}

Running this outputs:

Type 'a' please. 
a
Typ开发者_如何学编程ed 'a'.

On some forums people suggested using an Observer. And although this decouples the event handler from class being observed, I still have an if() on a forever loop.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Observable;
import java.util.Observer;

/* 
 * Example of checking a variable for changes.
 * This uses an observer to decouple the handler feedback 
 * out of the main() but still is polling.
 */
public class ObserverStillPolling {

    boolean typedA = false;

    public static void main(String[] args) {

        // this
        ObserverStillPolling o = new ObserverStillPolling();

        final MyEvent myEvent = new MyEvent(o);
        final MyHandler myHandler = new MyHandler();
        myEvent.addObserver(myHandler); // subscribe

        // watch for event forever
        Thread thread = new Thread(myEvent);
        thread.start();

        System.out.println("Type 'a' please.");

        String input = "";

        while (true) {
            InputStreamReader isr = new InputStreamReader(System.in);
            BufferedReader br = new BufferedReader(isr);

            try {
                input = br.readLine();
            } catch (IOException ioException) {
                System.out.println("IO Error.");
                System.exit(1);
            }

            // contrived state change logic
            // but it's decoupled now because there's no handler here.
            if (input.equals("a")) {
                o.typedA = true;
            }
        }
    }
}

class MyEvent extends Observable implements Runnable {
    // boolean typedA;
    ObserverStillPolling o;

    public MyEvent(ObserverStillPolling o) {
        this.o = o;
    }

    public void run() {

        // watch the main forever
        while (true) {

            // event fire
            if (this.o.typedA) {
                setChanged();

                // in reality, you'd pass something more useful
                notifyObservers("You just typed 'a'.");

                // reset
                this.o.typedA = false;
            }

        }
    }
}

class MyHandler implements Observer {
    public void update(Observable obj, Object arg) {

        // handle event
        if (arg instanceof String) {
            System.out.println("We received:" + (String) arg);
        }
    }
}

Running this outputs:

Type 'a' please.
a
We received:You just typed 'a'.

I'd be ok if the if() was a NOOP on the CPU. But it's really comparing every pass. I see real CPU load. This is as bad as polling. I can maybe throttle it back with a sleep or compare the elapsed time since last update but this is not event driven. It's just less polling. So how can I do this smarter? How can I watch a POJO for changes without polling?

In C# there seems to be something interesting called properties. I'm not a C# guy so maybe this isn't as magical as I think.

private void SendPropertyChanging(string property)
{
  if (this.PropertyChanging != null) {
    this.PropertyChanging(this, new PropertyChangingEventArgs(property));
  }
}

Yes, event handling is the key to your problem. The C# snippet you show also uses event handling to tell listeners that a property is changed. Java also has these PropertyChangeEvent's, which is used for most Beans. (For example: Swing components use them).

You can, however, do this manually: (though this isn't as POJO anymore, but more a Java Bean)

EventBean.java:

import java.util.LinkedList;
import java.util.List;

public class EventBean {

    private final List<Listener> listeners = new LinkedList<Listener>();

    protected final <T> void firePropertyChanged(final String property,
            final T oldValue, final T newValue) {
        assert(property != null);
        if((oldValue != null && oldValue.equals(newValue))
                || (oldValue == null && newValue == null))
            return;
        for(final Listener listener : this.listeners) {
            try {
                if(listener.getProperties().contains(property))
                    listener.propertyChanged(property, oldValue, newValue);
            } catch(Exception ex) {
                // log these, to help debugging
                ex.printStackTrace();
            }
        }
    }

    public final boolean addListener(final Listener x) {
        if(x == null) return false;
        return this.listeners.add(x);
    }
    public final boolean removeListener(final Listener x) {
        return this.listeners.remove(x);
    }

}

Listener.java:

import java.util.Collections;
import java.util.Set;
import java.util.TreeSet;

// Must be in same package as EventBean!
public abstract class Listener {

    private final Set<String> properties;

    public Listener(String... properties) {
        Collections.addAll(this.properties = new TreeSet<String>(), properties);
    }

    protected final Set<String> getProperties() {
        return this.properties;
    }

    public abstract <T> void propertyChanged(final String property,
            final T oldValue, final T newValue);
}

And implement your class like this:

public class MyBean extends EventBean {

    private boolean typedA;

    public void setTypedA(final boolean newValue) {
        // you can do validation on the newValue here
        final boolean oldValue = typedA;
        super.firePropertyChanged("typedA", oldValue, newValue);
        this.typedA = newValue;
    }
    public boolean getTypedA() { return this.typedA; }

}

Which you can use as:

MyBean x = new MyBean();
x.addListener(new Listener("typedA") {
    public <T> void propertyChanged(final String p,
                 final T oldValue, final T newValue) {
        System.out.println(p + " changed: " + oldValue + " to " + newValue);
        // TODO
    }
});

x.setTypedA(true);
x.setTypedA(false);
x.setTypedA(true);
x.setTypedA(true);

You misunderstand the observer pattern if your implementation of it uses polling. In the observer pattern, the method that changes the subject's state will cause subscribed observers to be notified before it completes.

Obviously, this means that the subject must support the observer pattern, you can not use any plain old java object as subject in the observer pattern.

You might also wish to look at the wikipedia example for the observer pattern.

In fact, the extra thread is unnecessary. You should let ObserverStillPolling extend Observable and notify the observers when input.equals("a").

Yes, this means that the POJO itself should extend Observable and notify the observers itself.

That said, the Observer/Observable are actually poorly designed. I'd suggest to homegrow your own interface PropertyChangeListener and let your POJO implement it. Then let either the POJO register itself with an observer during construction or do it dynamically by checking somewhere for instanceof PropertyChangeListener if applicable.

Perhaps the solution is wait()/notify() or one of Java's concurrency utilities. These constructs avoid the "busy-wait" polling that seems to be the point of the question.

These are used with multiple threads. One thread delivers the event, others respond to it. Here is an example:

class SyncQueue {

  private final Object lock = new Object();

  private Object o;

  /* One thread sends "event" ... */
  void send(Object o)
    throws InterruptedException
  {
    if (o == null)
      throw new IllegalArgumentException();
    synchronized (lock) {
      while (this.o != null)
        lock.wait();
      this.o = o;
      lock.notifyAll();
    }
  }

  /* Another blocks (without burning CPU) until event is received. */
  Object recv()
    throws InterruptedException
  {
    Object o;
    synchronized (lock) {
      while (this.o == null)
        lock.wait();
      o = this.o;
      this.o = null;
      lock.notifyAll();
    }
    return o;
  }

}