Re: java.util.ResourceBundle bug?

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

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