Re: [PATCH] support security.manager property

[Casey Marshall <csm at gnu dot org>]

>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:

Bryce> Casey Marshall wrote:
>> A nice property of this change is that natively linked binaries
>> (read: gcjappletviewer) can have a security manager set at
>> compile-time.
>> 
>> 2004-07-29  Casey Marshall <csm@gnu.org>
>> 
>> * prims.cc (_Jv_RunMain): install a security manager if the
>> `security.manager' property is set.
>> 

Bryce> Casey,

Bryce> This looks good, but I don't think _Jv_RunMain is the right
Bryce> place for this code. For one thing, it won't work when the
Bryce> runtime is started by invocation, because _Jv_RunMain isn't
Bryce> called.

I see. I think the security.manager property is most useful when
started from the command line, like via gij, which is why I thought
_Jv_RunMain, just before the FirstThread is created, was the best
place. It needn't be native; I just looked for the best place before
the main thread is created.

It might be that interpreting this property would be better built into
the class library. That way any VM that uses Classpath could take
advantage of this without modifying the VM itself.

Bryce> It looks to me like the code doesn't have to be native -
Bryce> wouldn't this be better done in the static initializer for
Bryce> java.lang.Runtime?

Perhaps, yes. Really I wanted to initialize it on the first *access*
to the security manager through java.lang.System, but the way the
security manager is kept in Runtime made that kind of difficult.

I also wasn't sure about bootstrap order, and accessing
System.properties and possibly class loaders so early.

-- 
Casey Marshall || csm@gnu.org