RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed

[Dmitry Samersoff]

Shanlinag,

The main goal of this fix - is preserve a compatibility in cross-version
environment upon request of JCK team.

i.e. it's possible to create an RelationNotification instance using
early version of JDK, set sourceObj to null, serialize it and give this
serialized object to latest update with the validation.

So we can't refuse such serialized stream and as soon as null
sourceObject can't cause any harm I decided to relax a
valiadation during *desereliazion*.

Constructor is not affected - it still throws IAE if sourceObj is null,
as it happens today and described in javadoc.

I'm not sure whether it make sense to change setSource as well to
prevent setting sourceObject to null in the future - probably yes, but
compatibility impact of these changes have to be evaluated separately
and it's clearly out of scope of this CR.

-Dmitry



On 2013-07-03 11:00, shanliang wrote:
> After reading again the constructor Javadoc:
> 
> "sourceObj - source object, sending the notification. This is either an
> ObjectName or a RelationService object. In the latter case it must be
> the MBean emitting the notification; the MBean Server will rewrite the
> source to be the ObjectName under which that MBean is registered."
> 
> In this case, should we override instead the method "setSource" to
> refuse a null value and do the necessary check? like
>    setSource(Object source) {
>       if (!(sourceObj instanceof RelationService) &&
>             !(sourceObj instanceof ObjectName))) {
>            throw new IllegalArgumentException();
>       }
>    }
>   Shanliang
> 
> shanliang wrote:
>> The constructor Javadoc says: "Throws IllegalArgumentException if no
>> source object", we have to modify the spec if the implementation is
>> changed.
>>
>> Shanliang
>>
>> Dmitry Samersoff wrote:
>>> Hi Everybody,
>>>
>>> *problem*
>>>
>>> Despite the fact, that validation in constructor of RelationNotification
>>> prohibit creation of the class instance with null sourceObj its possible
>>> to set it to null later by public setSource() method. So we should relax
>>> validation rules to preserve serialization behavior compatibility.
>>>
>>> *webrev*
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/
>>>
>>> *testing*
>>>
>>> JCK, no separate regression tests required.
>>>
>>>   
>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.