[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. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
