Java "events" - nothing more than Interfaces. Why pretend it is Events when it is just a normal Interface and classes that implements that interface?

Question

I am mainly developing in .NET C# and I love the Events in C#.

Im now doing som Android stuff and thus must deal with Java. When porting some code from C# to Java I ran into the problem of Events; Java does not have anything that corresponds to C# Events.

So, when reading up on how Java handles "events", the only thing I can conclude is that it doesnt. There is no such thing as "events" in Java. Instead they use normal Interfaces and classes that implement those interfaces.

In Java: First, you have to first create the Interface Then, all classes that want to listen to the "event" has to implement that interface. Then, the class that fires the "event" has to keep a list of all listeners (Array of some sort) Then, the class that fires the "event" has to have a method so that listeners can add themselves to the Array

And when the firing class decides to "fire the event", it has to iterate through the Array of the listeners, calling the methods.

That is just plain Interface-usage, not Events in my world.

Am I wrong?

Answer 1

JavaBeans is all about "convention over configuration". :-P Events are made by simply having methods that are named addXXXListener, removeXXXListener, and getXXXListeners, where the types involved derive from a listener interface.

In the same way, a property is made by simply having methods named getXXX and setXXX (either can be omitted for read-only or write-only properties).

How does a program locate events and properties? By using java.beans.Introspector, which puts those naming conventions into good use.

Sometimes, simplest is best. :-D

Answer 2

For clarification, the way the Android SDK implements and exposes the concept of an Event is distinct from the Java language. Different toolkits (i.e Swing, SWT) have their own way of doing things.

Answer 3

In Java, events represent all activity that goes on between the user and the application. Java's Abstract Windowing Toolkit (AWT) communicates these actions to the programs using events.

Answer 4

It is indeed just normal interfaces albeit with a naming and implementation "convention" - XXXListener and anonymous inner classes. I think this is fine and works well enough - the core language does not have to be bloated (maybe a little too harsh word for this - I don't want to start a flame war) by the notion of "events".

AFAIK Android draws inspiration for this pattern from Swing.

Note how most languages don't have a language construct for patterns like Singleton, Observer, ... it is not necessary if the patterns can be implemented easily - if it is a little more complicated it can be implemented by libraries, toolkits or frameworks.

Answer 5

No one is "pretending". The Java concepts were implemented long before C# was designed. The events in C# are really the same thing internally; though they are easier for the programmer to use. That is, the C# event variable maintains a list of event subscribing methods and the subscribers can add and remove method references from that list. The event provides a way for the owning class to trigger the event.

What is your definition of "event" anyway? This is a design pattern intended to decouple one system of classes from another. The other classes can subscribe to receive notification of an event in either case (C# or Java), it's just the implementation of that subscription and message trigger that differ.

In C# you must define the event method signature (a delegate). This is what interfaces do.

What C# does add that Java doesn't have is that you can pass references to methods (delegate, though I now understand this may become available in Java 7, at least at the JVM level). Since this does not exist in Java, there must be another means to provide event (an observer design pattern) receiver which must be an object and the best means to define this is through an interface -- yes you could use an abstract class, but that would severely limit the recipient types.