RFR: 8023447: change specification to allow RMI activation to be optional
stuart.marks at oracle.com
Sat Sep 7 00:31:00 UTC 2013
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
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.
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
> 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.
> 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:
More information about the core-libs-dev