[Mockry-developer] Classloading mechanism

[<Vin...@ge...>]

Been thinking about Mockry 2 this week-end.

I looked at AspectWerkz, JMangler and the Dynamic Mocks from mock objects.
We have very powerfull tools in hands and most of the funtionality is
already there:

1. The dynamic mock framework looks like 95% reusable. They have the
concepts of mocks, expectations, parameters, return values, ... We can reuse
95% of their code base. All we have to change is the Mock class that uses
JDK1.3 proxies to do the job.

2. AspectWerkz (using JMangler) brings the tools to modify classes &
interfaces at the methods & fields level.

There still are some things to work out though. First, I don't know yet if
we can use AspectWerkz using an API. All I've seen atm is configuration
files.

Secondly, JMangler cannot modify classes from rt.jar. JP was right and
classloading mechanism works this way:

1. Classes always ask the ClassLoader that loaded them to load any of their
dependent classes, and
2. ClassLoaders always delegate up the delegation tree to see if their
"parent" ClassLoaders wish to load the class first.

All classes in rt.jar will be loaded by the bootstrap classloader. Of
course, the bootstrap classloader is located in the VM and written in native
code.

However, I think we can get around this. What if we don't try to modify, say
String.class, but modify the class that uses String.class and make it use
MockString.class instead. I think that's how Agile Test from Polygenix does
it. Not sure thouhgt. I think all we need to do is ensure binary
compatibility of the MockString over String. Then we modify MockString using
AspectWerkz and make our class under test use MockString instead. Thoughts?

-- Vincent