getClassLoader()

[Godmar Back]

 Hi Vijay,

did you implement your proposed solution in any JVM?
If not, have you considered implementing it in Kaffe?
How do the two schemes compare in implementation complexity?
Could your scheme be made (ClassLoader) API compatible with 1.2's
scheme?  We will have to fix class loaders in Kaffe at some point...

Liang&Bracha state that your model would in their view violate the 
expectations user might have with regard to overloading, i.e., they claim
it's better to fail than to execute code that wasn't meant to be executed.
Do they have a point?

	- Godmar

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