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

[shanliang]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130617/84875fd3/attachment.html