Re: [PATCH] support security.manager property

[Bryce McKinlay <mckinlay at redhat dot com>]

Casey Marshall wrote:

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

Yeah, but there are other ways that it could be useful as well - 
consider a browser that starts libgcj via invocation to run applets 
in-process, for example.

Any access to the Runtime.securityManager will cause Runtime to be 
initialized, and thus its static initializers to be run, so by putting 
an initializer in Runtime, you ensure that the field gets initialized 
when (or before) it is accesse.

> 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.
>  
Yeah, since it doesn't really depend on any VM-specific functionality, I 
think this is the way to go. Its also more maintainable and better style 
to have the setting of the field close to where the field is defined, 
rather than have to dig through the startup code to find it.

> I also wasn't sure about bootstrap order, and accessing
> System.properties and possibly class loaders so early.
>  
Doing things early in startup does have the potential for hairy problems 
(co-dependent static initializers, etc), but I don't think doing it in 
Java code in this case is any worse than doing it in _Jv_RunMain, etc.

Regards

Bryce