Vijay Saraswat vj at
Tue Jul 28 02:55:27 PDT 1998

   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

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, 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.


More information about the kaffe mailing list