Archie Cobbs wrote: > Gary Benson wrote: > > Isn't the boot class loader solely for java.lang? > > No.. under the Java2 delegation model, the boot class loader > should be given the first chance to try and load *every* class. > > Typically it will only find classes in glibj.zip (or rt.jar, > or whatever your VM equivalent of the core library is) because > that's all it knows to look in. So then the child classloader(s) > get to try. > > In any case I'm still not clear on this problem. Yesterday it > looked to me like a result of delayed method resolution by kaffe. > But that could be completely off. I haven't actually witnessed > the problem so can't really say for sure without additional info. > > It would be nice however to get to the bottom of it before 0.20...
I think I figured it out. With the attached test I could reproduce the problem on IKVM as well. The attach Classpath patch fixing things, although past 0.20 I think we should refactor the security properties like I did with the system properties (i.e. introduce a gnu.classpath.SecurityProperties class). As you can see in the test, there is still the incorrect "charsetProvider" permission being checked. I'm looking into that one as well. Regards, Jeroen
testSM.java
Description: testSM.java
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
