On Mon, Dec 22, 2008 at 8:18 PM, Kevin Zhou <[email protected]> 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. -Nathan
