Re: System vs Runtime SecurityManager

[John Keisr]

Mark Wielaard wrote:

> Hi,
>
> Our vm/referemce/java/lang/Runtime.java defines the actual SecurityManager
> for use in System.get/setSecurityManager(). The class has the following note
> about why the securityManager field was moved from System to Runtime:
>
>        /* This was moved to Runtime so that Runtime would no
>         * longer trigger System's class initializer.  Runtime does
>         * native library loading, and the System class initializer
>         * requires native libraries to have been loaded.
>         */
>
> I don't completely understand how Runtime triggered the class initializer
> of System. And why if this happens it would actually be a problem.
>
> Are there any more of these subtle class initialization bootstrapping issues?
>
> Thanks,
>
> Mark
I remember that issue, bleagh ... I believe the reason Runtime was 
triggering System was, the code needed to get the security manager 
during class initialization somewhere and it was using 
System.getSecurityManager().  System class initializer was then 
triggered (class initializers are called on first use of the class).

I believe this was a problem because of a race-condition-like symptom:
- Runtime class initializer is called for whatever reason (probably VM 
starts it)
- Runtime causes System to be initialized /before/ it has loaded the 
libraries System needs
- System class initializer (or a class it uses) tries to use a native method
- Boom

I think that was it.  But it's been a long time, so our requirements for 
initialization and when to do loadLibrary() may have changed (doubtful) 
or I could be remembering wrong (a strong possibility).  I definitely 
don't remember why there wasn't a clean solution involving loading the 
libraries first--hopefully I would have thought of that, but I think I 
was on large doses of caffeine at the time.

A search in the archives of Classpath would reveal much.  I posted the 
message and it related specifically to Japhar.

--John