RFR: 8023447: change specification to allow RMI activation to be optional

[Olivier Lagneau]

Stuart,

Thanks for clarifying. I agree with minimization effort and your 
statements below.

So the this looks all fine !

Olivier

Stuart Marks said  on date 9/7/2013 2:31 AM:
> Hi Olivier,
>
> Thanks for looking at this. Part of the minimization effort (see my 
> reply to Alan) showed that ActivationGroupDesc needn't have the 
> throws-UOE specs added to it.  This is pretty easy to see by going to 
> the "Use" tab of the ActivationGroupDesc javadoc. ActivationGroupDesc 
> instances are returned and consumed by several instance methods of 
> ActivationSystem; this OK since we prevent the application from ever 
> getting any ActivationSystem instances, by specifying UOE wherever 
> they're returned. ActivationGroupDesc is also consumed by a static 
> method ActivationGroup.createGroup(). That has UOE on it, so we're 
> covered.
>
> The intuition behind this makes sense. If you look at 
> ActivationGroupDesc, it's just a "data class" -- it merely contains 
> Strings, MarshalledObjects, and Properties. Well, it has a 
> CommandEnvironment, but that's just a data class too. As such, 
> ActivationGroupDesc is just a bag of data that's used by the other 
> activation classes. (Note also that it doesn't throw any activation 
> exceptions anywhere.)
>
> Anyway, there's no harm in allowing apps to create ActivationGroupDesc 
> instances, so we didn't add UOE there. I tried similar analysis on 
> some of the other objects and was unsuccessful at convincing myself 
> they didn't need UOEs added to them, so that's how we ended up with so 
> many cases where throwing UOE is necessary.
>
> s'marks
>
> On 9/6/13 2:38 AM, Olivier Lagneau wrote:
>> Hi Stuart,
>>
>> I like this, and think this is the right approach for solving the 
>> problem.
>>
>> I see however that ActivationGroupDesc is not impacted by the change.
>> In the case of an implementation that does not support activation,
>> are we sure there will be no way for a developer to create an 
>> instance of any the other key activation classes
>> (ActivationGroup, ActivationDesc, ActivationGroupId, ActivationID), 
>> using an "Activatable" object (one that does not subclass
>> Activatable) and an ActivationGroupDesc instance, through any 
>> "default" behaviour described in the spec ?
>>
>> If that has been checked, that looks fine.
>>
>> Olivier.
>>
>>
>> Stuart Marks said  on date 9/6/2013 12:46 AM:
>>> Hi all,
>>>
>>> Please review this specification-only change to allow RMI activation 
>>> to be optional. RMI activation, unlike the rest of RMI, pretty much 
>>> requires the ability to fork processes at will. This causes 
>>> difficulties in certain situations, such as in small embedded 
>>> configurations. Activation is typically unnecessary in such 
>>> environments, hence it makes sense for it to be optional.
>>>
>>> Essentially the change is the addition of a small paragraph to the 
>>> package doc for java.rmi.activation, and adding spec for throwing 
>>> UnsupportedOperationException to a bunch of methods in this package.
>>>
>>>
>>> Bug report:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/
>>>
>>> Specdiff:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html 
>>>
>>>
>>> Thanks,
>>>
>>> s'marks
>>
>