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

[Olivier Lagneau]

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