On the other hand, could you provide a scenario where loading a
private copy of java.lang.String benefits a lot? Cheers.
Li
--Andrew Wright writes: > > I'm trying to understand the reason why ClassLoader and > SecureClassLoader (in jdk1.2) delegate to the parent class > loader *before* checking the local name space. "Java Security" > by Oaks on p. 35 gives a brief explanation that I don't get. > Paraphrasing: > when the class loader that loaded class C from url U is asked to > provide java.lang.String, it must provide the expected version and > not some some version from url U. > Why does this matter? If C gets the version of java.lang.String from > its own url rather than the system version, thats C's own problem. > It shouldn't bother any classes not loaded from U, as these still > get the system version of java.lang.String. > > Put another way, for class loaders to nest in a way that mimics > static (aka lexical) scoping, a class loader would first resolve > references within its own name space, and only try the parent > when it is unable to resolve the reference locally. Why don't > class loaders work this way? > > Andrew Wright, InterTrust >