RFR: 8023447: change specification to allow RMI activation to be optional
Stuart Marks
stuart.marks at oracle.com
Sat Sep 7 00:04:04 UTC 2013
On 9/6/13 12:44 AM, Alan Bateman wrote:
> On 05/09/2013 23:46, Stuart Marks wrote:
>> 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.
> Just to put more context on this, this is a continuation (and updated
> proposal) to the issue/proposal that Steve Flores brought up here back
> in July [1].
>
> Stuart's revised proposal looks okay. It initially feels like UOE is
> being allowed to be thrown from too many places (the ActiviationID and
> ActiviationGroupID constructors in particular) but once you get into the
> maze then they seem to be necessary. The proposal does mean there is a
> "porting effort" when you want to target a device that doesn't have the
> resources to fork new VMs but it shouldn't be too bad.
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018851.html
Hi Alan,
Thanks for linking this back to the earlier discussion.
Yes, I had thought there were too many UOEs thrown, and I spent a bunch
of time trying to minimize them, and I wasn't able to. Then Alan and I
spent a bunch more time going over it again and we still weren't able to
minimize it. It's a bit tedious to have UOE in so many places, but oh well.
s'marks
More information about the core-libs-dev
mailing list