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

[Andrew Clement <CLEMAS@xxxxxxxxxx>]

We are down in the dirty details aren't
we .... we fixed a 
number of problems with decompilation
in the run up to AspectJ1.2.  
AspectJ always generates valid bytecode
but certain decompilers 
(and even JVMs) aren't always compliant
with the JVM spec and they 
don't interpret the bytecode correctly
or they make certain assumptions
when they see certain patterns.  The
case below is an example that
I believe we have an open bug report
on.  The code we are creating in
aspectOf() is simply to check there
is a valid aspect instance
around.  The decompiler should
have said:

    public static NameChecking aspectOf()
     {
         if(ajc$perSingletonInstance == null) 
           throw new NoAspectBoundException(
             "org_codehaus_wadi_shared_NameChecking",
             ajc$initFailureCause);
           return
ajc$perSingletonInstance;
     }

Andy.

Jules Gosnell <jules@xxxxxxxxxxxxxxxxxx>
Sent by: aspectj-users-admin@xxxxxxxxxxx

28/05/2004 16:40

Please respond to
aspectj-users

To	aspectj-users@xxxxxxxxxxx
cc
Subject	Re: [aspectj-users] coverage, decompile, recompile

Thanks for the suggestion, Ron.

I tried that. Things look a little better - I don't get the inner class
problem first anymore - but this one instead :


/home/jgosnell/cvs/wadi/src/java/org/codehaus/wadi/shared/NameChecking.java:33
error Syntax error, insert "AssignmentOperator ArrayInitializer"
to 
complete _expression_
ajc$perSingletonInstance;
^^^^^^^^^^^^^^^
/home/jgosnell/cvs/wadi/src/java/org/codehaus/wadi/shared/NameChecking.java:34
error Syntax error on token "Invalid Character", throw expected
if(ajc$perSingletonInstance == null) goto _L2; else goto _L1


The code at this point has decompiled to :

     public static NameChecking aspectOf()
     {
         ajc$perSingletonInstance;    //
< line 33
         if(ajc$perSingletonInstance == null) goto
_L2; else goto _L1
_L1:
         return;
_L2:
         throw new 
NoAspectBoundException("org_codehaus_wadi_shared_NameChecking",
ajc$initFailureCause);
     }

     public static boolean hasAspect()
     {
         return ajc$perSingletonInstance != null;
     }


Line 33 looks very dodgy :-(. It looks like a variable declaration with
no type... JAD bug ?

I'm using :

aspectj1.2 for the original compile and recompile step.
jad v1.5.8e for the decompilation.


Should this sort of thing work, or am I wasting my time ?

Thanks for any help.


Jules



DiFrango, Ron wrote:
> Jules,
> 
> This is a known problem with AspectJ.  The following link should
get you to
> the bug report:
> 
>                  https://bugs.eclipse.org/bugs/show_bug.cgi?id=46298
> 
> One alternative approach you could take is to re-name your .aj files
to
> .java and the aspectj compiler will work fine.
> 
> Ron
> 
> -----Original Message-----
> From: Jules Gosnell [mailto:jules@xxxxxxxxxxxxxxxxxx] 
> Sent: Friday, May 28, 2004 10:32 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] coverage, decompile, recompile
> 
> 
> 
> 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
> 
> 


-- 
/**********************************
  * Jules Gosnell
  * Partner
  * Core Developers Network (Europe)
  *
  *    www.coredevelopers.net
  *
  * Open Source Training & Support.
  **********************************/

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users