[jira] Commented: (OPENJPA-244) Java 2 Security enablement

["David Jencks (JIRA)" <ji...@apache.org>]

    [ 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.

Re: [jira] Commented: (OPENJPA-244) Java 2 Security enablement

[Albert Lee <al...@gmail.com>]

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) <ji...@apache.org> 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.
>
>