event source

  • Thread starter =?ISO-8859-1?Q?Michael_M=FCller?=
  • Start date
?

=?ISO-8859-1?Q?Michael_M=FCller?=

Greetings,

I want to use an object as event source.
Reading the docs, I can't find anything. Maybe I'm blind...
java.awt.event may be used as event listeners.
Found nothing at java.util.event.
The only thing I found it throws / throwable, but this is used to raise
exceptions tb be cathced.
What I want to do is to raise an event, which I can use in a listener.
Anything special to do this?
Or just writing simple call back methods?
???
Michael
 
K

Knute Johnson

Michael said:
Greetings,

I want to use an object as event source.
Reading the docs, I can't find anything. Maybe I'm blind...
java.awt.event may be used as event listeners.
Found nothing at java.util.event.
The only thing I found it throws / throwable, but this is used to raise
exceptions tb be cathced.
What I want to do is to raise an event, which I can use in a listener.
Anything special to do this?
Or just writing simple call back methods?
???
Michael

Object o;

throw new AWTEvent(o,0);

Of course I really don't have clue what you are trying to do. A lot of
components generate events that you can then listen for (eg. Button).
 
Z

zero

Greetings,

I want to use an object as event source.
Reading the docs, I can't find anything. Maybe I'm blind...
java.awt.event may be used as event listeners.
Found nothing at java.util.event.
The only thing I found it throws / throwable, but this is used to raise
exceptions tb be cathced.
What I want to do is to raise an event, which I can use in a listener.
Anything special to do this?
Or just writing simple call back methods?
???
Michael

The most common way to raise an event is something like this:

interface MyEventListener
{
public void eventRaised(MyEvent e);
}

class MyEvent
{
public MyEvent() {}
}

class ObjectRaisingEvent
{
ArrayList<MyEventListener> listeners;

public void someMethod()
{
for(MyEventListener listener : listeners)
listener.eventRaised(new MyEvent());
}

public void addMyEventListener(MyEventListener listener)
{
listeners.add(listener);
}
}

The ObjectRaisingEvent class registers MyEventListeners. When the event
needs to be raised, you call the appropriate method on the event
listener. Note that you can have more than one method in the listener
interface, and decide which one to call based on the cause of the event.

Also, and more importantly, note that you don't actually need the MyEvent
class. It is very possible (and quite common) to just call a method on
the listeners without actually passing an event.

Depending on what it is you actually want to do, you can use this scheme,
or just use an existing event & listener.
 
?

=?ISO-8859-1?Q?Michael_M=FCller?=

zero schrieb am 28.11.2005 20:21:
The most common way to raise an event is something like this:

interface MyEventListener
{
public void eventRaised(MyEvent e);
}

class MyEvent
{
public MyEvent() {}
}

class ObjectRaisingEvent
{
ArrayList<MyEventListener> listeners;

public void someMethod()
{
for(MyEventListener listener : listeners)
listener.eventRaised(new MyEvent());
}

public void addMyEventListener(MyEventListener listener)
{
listeners.add(listener);
}
}

The ObjectRaisingEvent class registers MyEventListeners. When the event
needs to be raised, you call the appropriate method on the event
listener. Note that you can have more than one method in the listener
interface, and decide which one to call based on the cause of the event.

Also, and more importantly, note that you don't actually need the MyEvent
class. It is very possible (and quite common) to just call a method on
the listeners without actually passing an event.

Depending on what it is you actually want to do, you can use this scheme,
or just use an existing event & listener.
This seems to be, I'm searching for.
Thx
 
T

Thomas Hawtin

zero said:
ArrayList<MyEventListener> listeners;

public void someMethod()
{
for(MyEventListener listener : listeners)
listener.eventRaised(new MyEvent());
}

public void addMyEventListener(MyEventListener listener)
{
listeners.add(listener);
}

Noooo!!! ;)

If the result of a listener results in a listener being removed you'll
get into all sorts of trouble. Also the convention is to fire the
listeners in the opposite order, for some reason. Relying on that will
get you into trouble.

java.util.Observable has a novel solution. It makes a copy of the list
before firing - "Copy on Read". Copy on Write (CoW) is more normal.
However Copy on Read has the advantage that the copying overhead (almost
always absolutely insignificant, incidentally) happens at the less
time-critical point.

The normal approach is to use javax.swing.event.EventListenerList (and
yes, it is in completely the wrong package; no, it doesn't provide any
meaningfull degree of thread-safety). Grep the Swing source to see fire
methods that use it.

Tom Hawtin
 
Z

zero

Noooo!!! ;)

If the result of a listener results in a listener being removed you'll
get into all sorts of trouble. Also the convention is to fire the
listeners in the opposite order, for some reason. Relying on that will
get you into trouble.

java.util.Observable has a novel solution. It makes a copy of the list
before firing - "Copy on Read". Copy on Write (CoW) is more normal.
However Copy on Read has the advantage that the copying overhead
(almost
always absolutely insignificant, incidentally) happens at the less
time-critical point.

The normal approach is to use javax.swing.event.EventListenerList (and
yes, it is in completely the wrong package; no, it doesn't provide any
meaningfull degree of thread-safety). Grep the Swing source to see fire
methods that use it.

Tom Hawtin

I don't think it's very common to remove a listener as a result of an
event - and notice I didn't even provide a removeMyEventListener method,
so in the code snippet it wouldn't even be possible ;-) But yeah you're
right, it could happen. Making a copy of the list first seems like a
viable solution - though I wonder if there isn't a more elegant way.

IMHO EventListenerList would be more useful if it implemented List or Map
(since it "maps" the listener type to the listener).

Any idea why listeners are usually fired in reverse order?
 
T

Thomas Hawtin

zero said:
I don't think it's very common to remove a listener as a result of an
event - and notice I didn't even provide a removeMyEventListener method,

I think you'd be surprised. The other day I had a little demonstration
program that changed Look & Feel in response to a JList selection. The
NPE surprised me (not that I should be surprised by NPEs with my time
served). The change of L&F removed the PL&F's event listener, but it was
still present in the to be fired array. When it did get fired, the UI
delegate had be uninstalled. A quick EventQueue.invokeLater solved the
problem. Of course, when you install a new PL&F, it's listeners are now
later in the event list than the application's listeners.

Come to think of it, there is a technique (common within Swing itself)
where the listener maintains a weak reference to the object it mutates.
If the reference has been cleared, it removes itself in response to the
firing.
so in the code snippet it wouldn't even be possible ;-) But yeah you're

Even in the snippet you could have issues with listeners being added
during the firing, as you are using an Iterator.
right, it could happen. Making a copy of the list first seems like a
viable solution - though I wonder if there isn't a more elegant way.

Seems elegant to me. Perhaps I'm just used to that sort of thing. In 1.5
there's even java.util.concurrent.CopyOnWriteArrayList. Funny how things
become intuitive once learnt.
IMHO EventListenerList would be more useful if it implemented List or Map
(since it "maps" the listener type to the listener).

I don't see the use case for doing so. Also, it's a multimap rather than
a map, as it maps one type onto many listeners.
Any idea why listeners are usually fired in reverse order?

It's traditional? I think the original thinking was that even if a
listener removed itself, working backwards means that the unfired part
of the list is unaffected. Irrelevant with the current stronger
guarantees, but you don't want to go messing with behaviour unless you
have to.

Tom Hawtin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top