event source

Discussion in 'Java' started by =?ISO-8859-1?Q?Michael_M=FCller?=, Nov 28, 2005.

  1. 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
    =?ISO-8859-1?Q?Michael_M=FCller?=, Nov 28, 2005
    #1
    1. Advertising

  2. Michael Müller wrote:
    > 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).

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Nov 28, 2005
    #2
    1. Advertising

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

    zero Guest

    Michael Müller <> wrote in news:3v11e5F12f5suU1
    @individual.net:

    > 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.

    --
    Beware the False Authority Syndrome
    zero, Nov 28, 2005
    #3
  4. zero schrieb am 28.11.2005 20:21:
    > Michael Müller <> wrote in news:3v11e5F12f5suU1
    > @individual.net:
    >
    >> 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.
    >

    This seems to be, I'm searching for.
    Thx
    =?ISO-8859-1?Q?Michael_M=FCller?=, Nov 28, 2005
    #4
  5. zero wrote:
    >
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 28, 2005
    #5
  6. =?ISO-8859-1?Q?Michael_M=FCller?=

    zero Guest

    Thomas Hawtin <> wrote in news:438b6936$0$1461
    $:

    > zero wrote:
    >>
    >> 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


    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?

    --
    Beware the False Authority Syndrome
    zero, Nov 29, 2005
    #6
  7. zero wrote:
    >
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 29, 2005
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ~~~ .NET Ed ~~~
    Replies:
    1
    Views:
    4,179
    Cowboy \(Gregory A. Beamer\)
    Feb 26, 2005
  2. Marcus Leon
    Replies:
    5
    Views:
    578
    Marcus Leon
    Feb 3, 2005
  3. Cloud Burst
    Replies:
    11
    Views:
    1,016
  4. Author Tarun Tyagi
    Replies:
    0
    Views:
    694
    Author Tarun Tyagi
    Dec 29, 2004
  5. Guido Belligoi
    Replies:
    2
    Views:
    409
    Guido Belligoi
    Oct 19, 2006
Loading...

Share This Page