Re: minimal hack to classpath for ORP 1.0.9

[Fred Gray]

[Any further messages should probably go to only the classpath list, not 
the ORP list.]

On Sun, Mar 24, 2002 at 08:56:23PM -0600, Fred Gray wrote:
> On Sun, Mar 24, 2002 at 05:27:25PM -0700, Eric Blake wrote:
> 
> > Would it be worth
> > moving the default properties from System over to Runtime (the way the
> > default security manager was moved), and having Runtime use this VM
> > generated property list directly rather than relying on Runtime?

(I assume you mean "rather than relying on System".)

> I would say that this should be saved for a last resort; I'll stare at ORP 
> some more to see if I can figure out how to fix it there.  (I don't have much
> experience with ORP yet, so I can't make any promises.)

After further examination, the problem is clearly a Classpath bug, and the
solution is to do exactly what you said: move the default properties list into
Runtime.  

It's a straightforward bootstrapping problem, and it's apparently already been 
solved once in the past.  See the javadoc for Runtime.setSecurityManager():

   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.

The world starts out by initializing java.lang.Object.  Its static initializer 
does a System.loadLibrary(), which causes System to be initialized.  The static
initializer for System again calls System.loadLibrary(), which in turn calls 
Runtime.load(), causing Runtime to be initialized.  The static initializer for 
Runtime calls System.getProperty(), but the properties table hasn't been 
constructed yet, so "properties.getProperty(key)" tries to follow a null 
pointer.  Therefore the world ends in a giant kaboom. :-)

I initially thought that I might be able to get around this problem by 
removing the System.loadLibrary() call from System's static initializer
(not from Object's).  That just forces a different sort of crash when Math is
initialized before its native methods have been loaded.

I can pretty easily implement the fix for this, but I don't have copyright 
assignment paperwork, so it would probably be a month or three before it could
be checked in.  Given that this is a rather critical fix, someone else should 
probably write the patch.

Thanks,

-- Fred Gray