RFR JDK-8016592: Clean-up Javac Overrides Warnings In javax/management/NotificationBroadcasterSupport.java

Dan Xu dan.xu at oracle.com
Sun Jun 16 10:49:28 PDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130616/223052e2/attachment.html 


More information about the serviceability-dev mailing list