RE: [Mockry-developer] Classloading mechanism

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

You can't load a class if it's already been loaded by the parent
classloader. Thta's the rule cince classloader do upward delegation before
loading the class themselves. So you might be able to load File suing a
custom classloader if it's not been loaded by the bootstrap classloader,
i.e. when your bootstrap code was loaded. However, it certainly won't work
with String or Object ;-) So it's not a universal method. It we want to mock
the String class, I think we need to dynamically copy the String class,
modify the copy using aspects and replace in the class under test references
to String by references to MockString using BCEL. For custom or third-party
classes, it's easier since we can directly modify original classes thanks to
JMangler.

-- Vincent

> -----Original Message-----
> From: Jerome Fillon [mailto:fi...@vi...]
> Sent: Monday, May 05, 2003 14:32
> To: Vincent Tencé
> Cc: Moc...@li...
> Subject: Re: [Mockry-developer] Classloading mechanism
>
>
>
> Well actually you can load java.io.File in your own
> classloader. Maybe
> there is a limitation in JMangler.
> But it's possible.
> You can load a class in the original system loader and call a
> specific
> method that will create our own classloader and then load the classes
> needed.
> We must pay attention to how junit works as well....
>
> Let's spike! :)
>
>
> Vincent Tencé wrote:
>
> >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
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Mockry-developer mailing list
> >Moc...@li...
> >https://lists.sourceforge.net/lists/listinfo/mockry-developer
> >
> >
> >
>
>