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
