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
