getClassLoader()
Vijay Saraswat
kaffe@rufus.w3.org
Tue, 28 Jul 1998 05:55:27 -0400 (EDT)
Thanks for the pointer to Bracha's paper. So, did he design the new
delegating class loader paradigm in 1.2?
Delegating classloaders have always existed, they are not a new
concept. They are enabled merely by virtue of having arbitrary
user code run in defineClass, and having a separate
loadClass. The problem, in some sense, was that JavaSoft did not
realize that they did :)! See
http://www.research.att.com/~vj/bug.html.
All the JDK 1.1 loaders suffer from the "bridge attack" problem I
describe in my paper --- try it out and crash your favorite JVM
:) Fortunately, this attack cannot be launched by applets, hence
Javasoft wisely took its time to come up with a scheme to fix it,
since fixing this problem is not trivial. That scheme they
decided to go with is
http://java.sun.com/people/gbracha/classloaders.ps, and involves
posting binary compatibility constraints between classloaders
when delegation happens. Sheng Liang implemented it in JDK
1.2. It is a somewhat cumbersome scheme, and not what I had
recommended, but they felt that they had to go with a backward
compatible scheme. They are still considering my suggestion of
separating out the *binding* of a delagated class to its defining
classloader, and the loading of the actual classfile which
results in the definition of that class. So the story here is not
completely told.
Best,
Vijay