harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: Using PriviAction instead of PrivilegedAction
Date Tue, 23 Dec 2008 04:18:05 GMT
On Mon, Dec 22, 2008 at 8:18 PM, Kevin Zhou <zhoukevin83@gmail.com> wrote:
> Alexei wrote,
>> Could you please elaborate both variants a bit?
> Yes. PrivilegedAction is an interface which is used only for computations
> that do not throw checked exceptions. We also has a PriviAction
> implementation of PrivilegedAction interface. PriviAction is a helper class
> to avoid multiple anonymous inner class for doPriviledged/PrivilegedAction
> calls.
>> It is always a trade off between modularity and speed.
> :) Every time when you implement a doPriviledged/PrivilegedAction block, you
> need to add a anonymous inner class. PriviAction wraps some common
> doPriviledged/PrivilegedAction calls for system properties, security
> properties, security policy and so on.
> In a word, PriviAction can help to avoid multiple anonymous inner classes to
> make our code look better.
>> The performance measurement might be a part of Kevin's arguments.
> In fact, I don't know whether PriviAction may improve any performance.
> Only since we have such a PriviAction helper class, why not use it instead?

Modularity would be the reason. This would create a dependency on
every module to an implementation package in LUNI. As an alternative,
I'd suggest each module create one helper class, as needed, and reuse
that internally.

As I recall, PriviAction is quite an ugly class - it's rather a mess.


View raw message