Events-am I missing something?

[Srubys]

hi

I understand events to a point. I know that event is an object that
describes a state change in a source. Source generates an event when
its internal state changes in some way. Listener is an object, which
if registered for particular event will be notified when event occurs.
Source registers listeners via registration methods, while listeners
are able to get registered only if they implement certain interface
for that event. This interface provides listener with method(s) that
actually receive and process events.

* I’m not sure how to get my point across, but I will try:
I don’t understand what the big deal is about event handling
mechanism. Meaning, all the procedures I described above a programmer
could create easily, even if Java didn’t provide us with the so
called event delegation model . Only difference is that Java has given
us some already defined events and some already defined interfaces to
handle those events and some already defined source classes with their
registration methods. Point being, I thought that internally this
event handling mechanism provided programmer with utility, which would
be very hard or almost imposible to achieve by programmer alone
( assuming if Java haven’t provide predefined classes for it ), but
that doesn’t seems to be the case ( on the other hand, exceptions are
something programmer would not be able to create by itself, if Java
didn’t internally provided support for them)


*All the tutorials I found on the net describe event handling within
the context of AWT, or SWING or … controls. Since I haven’t started
learning those yet and since I would like to figure out more of what
is happening under the hood, do you know of any tutorials, which would
explain ( and show code ) events without the use of those “fancy”
applet, AWT … libraries?


cheers

 

[Stefan Ram]

I know that event is an object that
describes a state change in a source.

To which context (like »Swing«, »Java«, or »programming«)
does this refer?

Which source (for example, which book) is this definition
based on?

I don't understand what the big deal is about event handling
mechanism.

Which source claimed that this is a »big deal«?

called event delegation model

This was only intended to get the attention of persons who
were used to the AWT model based on inheritance, so that they
learn the new Swing model.

out more of what is happening under the hood, do you know of
any tutorials, which would explain ( and show code ) events
without the use of those ''fancy'' applet, AWT ... libraries?

I have written a page about events in Java without reference
to Swing or AWT, but this page is written in German language:

http://www.purl.org/stefan_ram/pub/ereignisse-java

 

[Mark Space]

hi

I understand events to a point. I know that event is an object that

One thing you might try is to implement your own dispatch mechanism, and
see how the implementation turns out. Make your own JFrame and JButton
(like for example a simple message dialog) and understand how those work
when they don't use an event system.

How do you implement a "when button pressed" method when you don't use
events? Then try to imagine extending that technique to a large
application and think about what issues might turn up.

It should be an interesting change from programming to delve into the
more software engineering aspects for a while.

 

[Daniele Futtorovic]

What the OP has to learn is that there is magic in the event mechanism
and in event-driven architectures.

Not "magic" in the sense the OP described. Nothing a Java programmer
couldn't build a replacement for if it were missing -- as opposed to,
f.i., Exception mechanisms.

I came to event-driven programming early, in C, both for GUI programming
and other contexts. I've used it in C++, FoxPro, and of course, in
Java. It's a powerful (though, of course, not all-powerful) structure.

Its advantages are loose coupling and the concomitant reduction in
program state complexity, ready scalability, flexibility and a sort of
magic. Its main disadvantage is a rather sharp fragmentation of overall
system logic, which can make it hard to track down relationships that
tend to exist only at run-time. You also could give up some type
safety, a risk the Java way tends to reduce.

Event-driven architecture is pretty much /de rigueur/ for distributed
systems.

For those times when you want event-driven programming, the Java
framework is pretty adequate. It occurs to me as I write this that
pieces of it could serve in novel ways, given on the relatively reliable
nature of the built-in APIs. For example, the business of registering
listeners is similar to the business in MVC systems of registering
handlers for view requests.

They're tools, events, handlers, and the convenient, built-in Java
libraries to facilitate them.

I very much agree with you that an event-driven architecture is lege
artis and powerful (and even beautiful), yet IMO it's more of a concept
Java allows you to implement fairly easily than much of a specific tool
Java provides you with.

Of course Java sports a lot of built-in event code, especially in GUI
libraries. If you write non-GUI, event-driven code, you might use
ChangeListeners or PropertyChangeListeners or others. But if you want to
write your own events, what parts of the JDK will you use? EventObject,
EventListener, EventListenerList, EventQueue. That's not a whole lot.

 

[Chronic Philharmonic]

A lot of people have already weighed in on this, but I thought I'd kick in
my $0.02.

Events in Java are "design patterns". Java provides a couple of specific
features (java.util.EventObject), and makes good use of interfaces to
implement the events pattern. There is very little else in the way of object
or language support. Programmers are expected to follow standard design
patterns and naming conventions to implement event sources and event
listeners.

The Java Beans specification
(http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html)
describes the events design pattern and shows some typical ways of
implementing event listeners and event sources. The original Java Beans spec
showed (and the current version still shows) event sources implemented using
Vector to hold the registered listeners. Today, I typically use a
synchronized ArrayList to hold my listeners. It allows me to do this
(without having to explicitly synchronize my methods -- the relevant calls
into ArrayList are synchronized for me):

/** List of registered listeners. */
private List<IServiceListener> m_listeners =
Collections.synchronizedList(new ArrayList<IServiceListener>());

/**
* Standard design pattern registers a new service listener.
* @param listener to add.
*/
public void addListener(IServiceListener listener) {
m_logger.config(listener.toString());
m_listeners.add(listener);
}

/**
* Standard design pattern unregisters a service listener.
* @param listener to remove.
*/
public void removeListener(IServiceListener listener) {
m_logger.config(listener.toString());
m_listeners.remove(listener);
}

/**
* Event Source. Fires data changed event when data is added.
* @param event contains the data being added.
*/
public void dataAdded(DataEvent event) {
IServiceListener[] listeners =
m_listeners.toArray(new
IServiceListener[m_listeners.size()]);

for (IServiceListener listener : listeners) {
try {
listener.dataChanged(event);
} catch (Exception warning) {
m_logger.warning(toMessage(warning));
m_listeners.remove(listener);
}
}
}

In many respects, events (in Java and other environments, such as
ActiveX/COM/.net) are simply glorified callback mechanisms to which you can
register for notification that something happened, e.g., an asynchronous
process completed. The Java event design patterns simply helps everyone do
things approximately the same way, and the naming conventions help tools
discover and use the event facilities of an object through
reflection/introspection.

 

[Srubys]

hiya

I have written a page about events in Java without reference
to Swing or AWT, but this page is written in German language:

http://www.purl.org/stefan_ram/pub/ereignisse-java

Page looks very informative,but unfortunatelly my knowledge of german
in pretty non existent. I suppose it would be too much to
ask if maybe you could translate it,sinceI imagine there are lotsof
Java beginners who'd love to see events examplesin non GUI setting ( I
know that would take a lot of time, but
I had to ask )?

You are right: There is nothing "special" about events,
and every programmer in the world could implement something
similar to the scheme Java provides. But all those different
programmers would probably implement slightly different things,
and they couldn't interoperate: a SrubysEventGeneratingThing
could only send event notifications to a SrubysEventListener
and not to an EricsEventListener. By providing a pre-defined
set of classes and interfaces, Java encourages programmers to
write code that can work with other programmers' code. If a
the SrubysEventGeneratingThing can notify ActionEventListeners
when its state changes, then all I need to do is implement an
ActionEventListener to get my code to work with yours.

So even when writting your own events, the sources you'd create should
require listeners to implement already existing
listener interfaces ( for example ActionEventListeners interface )?



thank you all

cheers

 

[Stefan Ram]

ask if maybe you could translate it,

I have added it to my to-do-list, but since

that would take a lot of time

it cannot be done immediatly.

(The problem with versions of a web page in multiple languages
is not so much a single translation, but the maintenance:
Whenever you change something in one version, you need to
change the other versions, too. So only about one half of the
improvements can be applied to the set of all text within the
same span of time.)

One starting point from the page is my definition of »event«:

While an operation is being defined by its behavior and might
be invoked at any time such behavior is needed, an event has
the oppositional semantics: It is defined by the circumstances
under which it will be invoked and might then trigger any
behavior. So we have:

trigger behavior

operation unspecified specified

event specified unspecified

Also, as others possibly already have said: Events appear,
when the part of a program handling requests is being
separated from the part of a program generating requests.
Then, events appear at the interface of both parts modelling
these requests. They allow to replace one of those parts by
any other part implementing the same interface.

 

[Srubys]

I have added it to my to-do-list, but since

That would be greatly appreciated

cheers mate