harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Using PriviAction instead of PrivilegedAction
Date Wed, 24 Dec 2008 11:44:14 GMT
Pavel Pervov wrote:
> As I see it this class only solves the problem of "the more anonymous
> classes - the larger disribution is" problem. That is all. I assume we
> want to move toward solving that problem, but I'm not quite sure if we
> want to achieve it by using _single_ helper class for all the class
> library.

So how is this use of PriviAction:
  new PriviAction<String>("line.separator")

producing fewer anonymous classes than this use of PrivilegedAction:

  new PrivilegedAction<String>() {
    public String run() {
      return System.getProperty("line.separator");

It is more compact in source code, but...<shrug/>


> On Wed, Dec 24, 2008 at 2:10 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> I didn't see a good answer to Alexei's question...
>> Alexei Fedotov wrote:
>>> Pavel,
>>> Kevin didn't mention performance, did he?
>>> I believe it is always a trade off between modularity and speed. The
>>> performance measurement might be a part of Kevin's arguments if his
>>> intentions are to improve the performance. That is why I asked him to
>>> elaborate both approaches uncovering intentions.
>>> If our internal security interfaces are much quicker on real
>>> applications I would wonder why our public interfaces are so slow.
>> What problem is the PriviAction solving?  I see the class comment [1] says:
>> "Helper class to avoid multiple anonymous inner class for
>> java.security.AccessController#doPrivileged(PrivilegedAction) calls."
>> Is that really a problem?  For readability or performance?
>> [1]
>> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/util/PriviAction.java?revision=486600
>> Regards,
>> Tim

View raw message