Re: [aspectj-users] Using the -injar compiler option

[James Howe <jwh@xxxxxxxxxxxxxx>]

I'll write up a bug report.  As to weaving rt.jar, I would love to come up 
with an alternative solution, but right now it's the only easy solution 
I've come up with.  Here's an example of the sort of thing I'm trying to 
work with.  Suppose I have a method on a class that needs to do something 
if a file doesn't exist.  The code would be written to use the Java file 
class.  It might instantiate an instance of file based on a name and then 
ask the File if it exists.  What I want to be able to do is configure my 
test case to use a MockFile instead of the real file.  File doesn't 
implement an interface so I have to go through gymnastics to come up with a 
MockFile.  I would then have to rewrite the method to take a File as a 
parameter (in reality some cooked up File interface) which could then be 
swapped out for a MockFile at test time.  What I'm thinking is that I would 
like to have some 'woven' system jars that could be used during 
development/testing and and runtime the regular jars would be used.

On Thu, 15 May 2003 13:38:28 -0700, Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:

> Hmm... looks like a cycle in the InstructionHandle list:
>
> ---- Utility.java
> public static int getSourceLine(InstructionHandle ih) {
> if (ih == null) return -1;  <snip...>
> return getSourceLine(ih.getNext()); // StackOverflow here
> }
> ----
>
> It doesn't seem like this *should* be a side-effect of decompiling 
> classes also in the parent loader, but...
>
> In any case, it's definitely worth writing up as a bug.
>
> http://dev.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
>
> (Weaving rt.jar seems like a lot of work to isolate test cases;
> is there some other way to do it?  We don't recommend users
> weave Java classes.)
>
> Thanks for bringing this up -
> Wes




--
James Howe