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/>
Regards,
Tim
> On Wed, Dec 24, 2008 at 2:10 PM, Tim Ellison <[email protected]> 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
>>
>
