305 return listener.hashCode();
Could get a NullPointerException because the listener could be null, the
method removeNotificationListener does not refuse a null listener.
I think this must be a new bug, the method removeNotificationListener
should throw an exception in case of a null listener, with the current
implementation a user might get a ListenerNotFoundException when
removing a null listener, but we never allow to register a Null listener.
Shanliang
Dan Xu wrote:
On 06/15/2013 09:26 AM, Alan Bateman wrote:
On 14/06/2013 20:49, Dan Xu wrote:
Hi,
I have a simple fix to clean up the new javac overrides warnings in
NotificationBroadcasterSupport.java file. Please help review it. Thanks!
webrev: http://cr.openjdk.java.net/~dxu/8016592/webrev.00/
<http://cr.openjdk.java.net/%7Edxu/8016592/webrev.00/>
bug: http://bugs.sun.com/view_bug.do?bug_id=8016592
-Dan
I don't know this code but it looks to me that ListenerInfo.equals
doesn't really need to check if the object is a WildcardListenerInfo.
That is, I assume there aren't ListenerInfo instances that have a
null filte and handback==null but aren't a WildcardListenerInfo. In
any case, the hashCode looks fine.
WildcardListenerInfo looks okay too although for consistency then it
should probably use super.hashCode() so it's more obvious when
checking it against the equals method.
-Alan.
Hi Alan,
When I initially read the code, I also had doubts about the equals()
methods. And Daniel Fuchs sent me a very good clarification on the
code trick here.
"
When a client adds a listener to an MBean he can give, in addition
to the listener, a filter and a handback.
These three elements are wrapped inside a ListenerInfo - which is
added to the mbean's listenerList (which BTW is a list of ListenerInfo,
not a list of Listener).
However, when removing a listener, there are 2 methods that a client
can call:
One that takes a listener, a filter, and a handback, in which
case a new ListenerInfo is created with these three elements,
and any ListenerInfo that matches in the list will be
removed.
The other one only takes a listener, and the semantics is
that any ListenerInfo that has the same listener should be
removed, disregarding with which handback or filter it was
registered. In that case we create a WildcardListenerInfo, which will
match
any ListenerInfo that has the same listener - disregarding of the
value of the handback and filter.
"
Therefore, when a ListenerInfo instance compares with a
WildcardListenerInfo object, only the listener element counts. If a
ListenerInfo instance compares with another ListenerInfo object, all
three elements, listener, filter, and handback, are needed to be
compared. Thanks!
-Dan
