Re: ClassLoader question

Li Gong (gong@games.eng.sun.com)
Mon, 7 Dec 1998 21:39:55 -0800

In theory the classloader can load and define its private copy of
java.lang.String. But this is of not much use, because it will
potentially render classes loaded by this classloader non-interactable
with classes loaded by other classloaders that use the system copy of
java.lang.String. When two classes that have different notions of
what java.lang.String meet (like reference each other directly or
indirectly), a type safety error will occur. Given this, you can
achieve what you describe by invoking a fresh copy of the JVM where
you can probably define your own code.

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 >