The doPrivileged incurred 2 method calls, i.e. the doPrivilege() and the
PrivilegedAction.run method(). If security is disabled, there is no
additional cost involved at runtime, other than the 2 method calls. As the
JVM stablized at runtime, these method calls may be optimized by JIT
compiler. That's one of the reason the final qualifier is used in the static
methods to 'help' this JIT optimization.
The static helper may also do what you suggested. That is, determine if
security is on in class static {} and each method can skip the doPrivileged
if security is disabled.
Since there is no state needs to be maintained, we choose to use the static
method instead. Use of static instance is doing the same function except
there is an object to be managed. In addition, there is a call to obtain the
static instance before the method can be called. If there is reason we need
multiple instances (i.e each instance has states info in them) or other
desired side effects, we believe the direct method call is more efficient
and appropriate.
Thanks for your comments and suggestions.
On 6/3/07, David Jencks (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501024]
David Jencks commented on OPENJPA-244:
--------------------------------------
Would it make any sense to, rather than having a class with static
methods, having an interface/abstract class and a static INSTANCE? Then
some initialization (static) code could decide which implementation is
appropriate for the environment: e.g. if no security manager is installed
we wouldn't need the doPrivileged code? I don't know if going through the
doPrivileged code when it isn't doing anything incurs enough expense to make
this worthwhile.
> Java 2 Security enablement
> --------------------------
>
> Key: OPENJPA-244
> URL: https://issues.apache.org/jira/browse/OPENJPA-244
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 0.9.8
> Reporter: Kevin Sutter
> Attachments: J2DoPrivHelper.java
>
>
> Via some testing with the WebSphere Application Server, it's been
discovered that we're missing some doPriv blocks through out the OpenJPA
code base. This JIRA report will be used to resolve these issues. More
specific examples will be posted later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
