RFR: 8023447: change specification to allow RMI activation to be optional
olivier.lagneau at oracle.com
Mon Sep 9 15:02:52 UTC 2013
Thanks for clarifying. I agree with minimization effort and your
So the this looks all fine !
Stuart Marks said on date 9/7/2013 2:31 AM:
> 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
> 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.
> 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