Re: java.util.ResourceBundle bug?

[Bryce McKinlay]

[cc'ing classpath - see below]

Boehm, Hans wrote:

> Hans> Unless I'm mistaken, the stopgap implementation of
> Hans> java.util.ResourceBundle.getClassContext() in
> Hans> natResourceBundle.cc is broken.
>
> I agree.

Well spotted - this bug was causing libjava to be pretty much totally 
broken on PowerPC, and all this time I thought it was a miscompilation 
(no thanks to GCC not being able to compile libjava without -O on PowerPC).

> Hans> -  elts[0] = java::lang::ClassLoader::getSystemClassLoader ();
> Hans> +  elts[0] = &java::lang::Object::class$;
>
> Based on comments in ResourceBundle.java, I think the right patch is
> to use:
>
>    elts[0] = &class$;
>
> (i.e., the ResourceBundle class.)
> Feel free to check this in if you'd like to make the change.

I think the correct fix is to remove this method 
(ResourceBundle.getClassContext) and natResourceBundle.cc altogether. 
There is no reason to have a separate implementation of 
getClassContext() here, instead it should call the static implementation 
in VMSecurityManager. The problem is that VMSecurityManager is in 
java.lang and package-private, but I don't think it should be, since 
there are classes in other packages which need access to this 
functionality.

I think we should move it to gnu.java.lang and make it public. Same goes 
for java.lang.VMClassLoader. Does anyone disagree?

regards

Bryce.