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

[Stuart Marks]

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
>