Re: [aspectj-users] coverage, decompile, recompile

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

fyi, I just realized there's an alternative to binary weaving
(which has it's own limitations wrt reporting errors):

  <clover-setup ...
      clovercompiler="${aspectj.build.compiler}"/>

This way, clover does its source-level instrumentation, and
then passes the result not to javac, but to ajc.

Normally when using build.compiler for Ant's javac task,
you can specify per-compiler arguments with a nested
<compilerarg>.  I'd be interested to know whether those
worked when Clover is responsible for the delegation.

Wes

Jules Gosnell wrote:

> Wes Isberg wrote:
>
> > I use AspectJ with Clover all the time:
> >
> >   - javac (read: clover via Ant's build.compiler property)
> >   - ajc does binary weaving
> >
> > A good rule of thumb for builds is for ajc/AspectJ to go last.
> > Since a build cycle always ends by producing .class files,
> > ajc can always weave and produce valid .class files at the end.
> >
> > Doing it this way is nice because many tools integrate
> > using Ant's build.compiler property, and it requires no
> > change to the build script when using new tools.  It's
> > also easy to support development-time only aspects by
> > setting a flag that determines whether the final weave runs.
> >
> > AJDT and other IDE integrations should be set up with the
> > same semantics.   (When they get around to supporting
> > sourcepath mapping for binary files, the integration should
> > work well.)
> >
> > Regards,
> >
> > Wes 
>
>
> Wes,
>
> Thanks for this. I'll give it a try.
>
> Would it be correct to assume that if built this way only the .java 
> files will actually be instrumented by clover and the .ajs, which are 
> compiled and woven in later by aspectj will not ?
>
>
> Jules
>
>
>
> > (The "decompilers" that we support are the VM, javac, jikes,
> > and the eclipse compiler.  As far as I know, they have
> > no problems with .class files produced by ajc.)
> >
> > Jules Gosnell wrote:
> >
> > > Because AspectJ compiles directly from .aj to .class with no 
> > > intermediate .java stage, I am currently thwarted in my efforts to 
> > > run e.g. Clover over my codebase to do coverage testing.
> > >
> > > Clover only understands Java (AFAIK).
> > >
> > > I guess this must be the situation for a number of useful tools.
> > >
> > > I recently had the idea of compiling .aj to .class, decompiling 
> > > .class to .java and then recompiling .java back to .class with clover...
> > >
> > > Needless to say this was wishful thinking (I used the latest JAD, 
> > > which wasn't happy with the version of my class files). The first 
> > > recompilation error, of many, turned out to be an inner class that 
> > > had got lost - further investiation revealed that jad had failed to 
> > > decompile it :
> > >
> > > WEB-INF/classes/org/codehaus/wadi/jetty/Manager$HouseKeeper.class...The 
> > > class file version is 48.0 (only 45.3, 46.0 and 47.0 are supported)
> > >  Generating jad/org/codehaus/wadi/jetty/Manager$HouseKeeper.java
> > > Couldn't resolve all access$ methods in method run
> > >
> > > Has anyone else tried anything like this ?
> > >
> > > Is it possible to decompile Aspectj programs back into Java, or do 
> > > they contain untranslatable bytecode ?
> > >
> > > Is there a better decompiler around ?
> > >
> > > Cheers,
> > >
> > >
> > > Jules
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users