Composite Materials

Events as a first-class concept

Event-based programs have been with us for a long time, and are getting more common. Things ranging from major business happenings to an XML element being parsed to a mouse movement are processed as events, delivered in various ways to code. Regardless of the use case, events are generated by a producer, and delivered to consumers (zero or more). Events can be delivered from producer to consumer synchronously (with the possibility of the consumer affecting the producer, by means of the event data), or asynchronously, where consumer is informed of an event separately from the producer "sending" it.

Events are, in the Java world, usually represented by objects. The mechanism for the producer to send an event, and the mechanism used to receive an event, is generally by convention. JavaBean propertyChangeEvents and propertyChangeListners are a perfect example of a synchronous delivery mechanism. Code and convention, mixed with the safefy that a strongly type language gives us, are combined to make for a workable event handling system.

What would it look like if we elevated the concept of events to the Java language itself? What if posting an event was a simple as:

    post bean.Changed;

and registering for an event was as simple as:

    Timer timer = new Timer(5000);
    timer.start();

    switch event  {
       case bean.Changed :
           // ...
       case okButton.Click :
           // ...
           break;
       case timer.Expired :
           // ...
           break;
    }

and an event processing loop looks something like:

    do event {
        case addButton.Click :
            // ...
            break;
        case updateButton.Click :
            // ...
            break;
        case entryField.MouseOverEvent :
            // ...
            break;
    } until (done)

or even the ability to use events to convey the normal and abnormal termination of a thread:

    Thread thread;
    // Initialise the thread.

    switch event {
        case thread.Done :
            break;
        case thread.Aborted :
            break;
        postregister : // do this after this thread is registered for the events in this switch
            thread.run();
    }

You get the idea. Obviously this needs further thought, but the basic ideas are well-founded, since I have lifted them from the Forté language, TOOL.

Aside from the syntactic niceties, are there any other advantages to this? Decidedly yes! Firstly, it makes it very easy to wait for events from multiple sources. Next, the run-time is now "event" aware, so it can do some useful things, like find deadlocks, or provide management reports about the state of each thread that is blocked on events (very useful for debugging multi-threaded apps).

This also avoids some of Java's low-level inter-thread communication mechanisms (Object.wait()/notify()), which are difficult for the average programmer to use, and make code fairly unreadable. This mechanism also makes the compiler more useful, since it adds some degree of type-safety to events.

Just a thought...

Posted at 08:19AM Apr 18, 2006 by rtenhove in Java  |  Comments[1]