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

[Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>]

I'd love to see this change integrated and test it out with JRockit. Let me know when it happens...

Cheers,
Nick
On Jun 2, 2004, at 2:36 AM, Andrew Clement wrote:

> <x-tad-smaller>Sorry Nick, I wasn't telling you off :)  I know this discussion</x-tad-smaller> 
> <x-tad-smaller>is now moving onto how to use clover with source but I still</x-tad-smaller> 
> <x-tad-smaller>want to say something about decompilation. (Sorry, this next bit</x-tad-smaller> 
> <x-tad-smaller>is more aspectj-dev'ish than aspectj-users'ish...)</x-tad-smaller> 
>
> <x-tad-smaller>I have now rewritten the generator for the aspectOf() method </x-tad-smaller>
> <x-tad-smaller>and it is producing code that even 'dumb' decompilers can </x-tad-smaller>
> <x-tad-smaller>understand.  Here is a decompiled aspectOf() method with my </x-tad-smaller>
> <x-tad-smaller>compiler patch in:</x-tad-smaller> 
>
> <x-tad-smaller>public static A aspectOf() {</x-tad-smaller> 
> <x-tad-smaller>  if (ajc$perSingletonInstance == null)</x-tad-smaller> 
> <x-tad-smaller>    throw new NoAspectBoundException("A",ajc$initFailureCause);</x-tad-smaller> 
> <x-tad-smaller>  else</x-tad-smaller> 
> <x-tad-smaller>    return ajc$perSingletonInstance;</x-tad-smaller> 
> <x-tad-smaller>}</x-tad-smaller> 
>
> <x-tad-smaller>I did *not* want to make this change if it damages runtime </x-tad-smaller>
> <x-tad-smaller>performance in any way change so I have run all the performance</x-tad-smaller> 
> <x-tad-smaller>benchmark tests we have - it seems to, on average, be 1% faster </x-tad-smaller>
> <x-tad-smaller>with the alternative implementation of aspectOf.  So, it's not </x-tad-smaller>
> <x-tad-smaller>slower and maybe the JIT/JVM are recognizing the alternative</x-tad-smaller> 
> <x-tad-smaller>bytecode sequence as an easier pattern to optimize.</x-tad-smaller> 
>
> <x-tad-smaller>I'm hoping to integrate this shortly - depending on how the</x-tad-smaller> 
> <x-tad-smaller>rest of the dev team feel about it?  And I'd also like to see</x-tad-smaller> 
> <x-tad-smaller>if it makes a difference to the latest JRockit issue that</x-tad-smaller> 
> <x-tad-smaller>you raised Nick :)</x-tad-smaller> 
>
> <x-tad-smaller>cheers,</x-tad-smaller> 
> <x-tad-smaller>Andy.</x-tad-smaller> 
>
>
>
>
>
> <x-tad-smaller>Nicholas Lesiecki <ndlesiecki@xxxxxxxxx></x-tad-smaller><x-tad-smaller> </x-tad-smaller>
> <x-tad-smaller>Sent by: aspectj-users-admin@xxxxxxxxxxx</x-tad-smaller>
> <x-tad-smaller>28/05/2004 19:59</x-tad-smaller>
> <x-tad-smaller>Please respond to</x-tad-smaller>
> <x-tad-smaller> aspectj-users</x-tad-smaller>
> <x-tad-smaller>To</x-tad-smaller>
> <x-tad-smaller>aspectj-users@xxxxxxxxxxx</x-tad-smaller>
> <x-tad-smaller>cc</x-tad-smaller>
> <x-tad-smaller>Subject</x-tad-smaller>
> <x-tad-smaller>Re: [aspectj-users] coverage, decompile, recompile</x-tad-smaller>
> <x-tad-smaller>My apologies for claiming that decompiling did not receive attention. I  </x-tad-smaller>
> <x-tad-smaller> was misinformed.</x-tad-smaller>
>
> <x-tad-smaller> Also, I didn't mean to imply that AspectJ was at fault in  </x-tad-smaller>
> <x-tad-smaller> incompatibility problems. IMHO most decompilers are not nearly as  </x-tad-smaller>
> <x-tad-smaller> sophisticated or well-engineered as AspectJ. I'd place the fault with  </x-tad-smaller>
> <x-tad-smaller> them.</x-tad-smaller>
>
> <x-tad-smaller> Cheers,</x-tad-smaller>
> <x-tad-smaller> Nick</x-tad-smaller>
>
>
> <x-tad-smaller> On May 28, 2004, at 9:14 AM, Andrew Clement wrote:</x-tad-smaller>
>
> <x-tad-smaller> ></x-tad-smaller>
> <x-tad-smaller> > We are down in the dirty details aren't we .... we fixed a</x-tad-smaller>
> <x-tad-smaller> > number of problems with decompilation in the run up to AspectJ1.2.  </x-tad-smaller>
> <x-tad-smaller> > AspectJ always generates valid bytecode but certain decompilers</x-tad-smaller>
> <x-tad-smaller> >  (and even JVMs) aren't always compliant with the JVM spec and they</x-tad-smaller>
> <x-tad-smaller> > don't interpret the bytecode correctly or they make certain assumptions</x-tad-smaller>
> <x-tad-smaller> > when they see certain patterns.  The case below is an example that</x-tad-smaller>
> <x-tad-smaller> > I believe we have an open bug report on.  The code we are creating in</x-tad-smaller>
> <x-tad-smaller> > aspectOf() is simply to check there is a valid aspect instance</x-tad-smaller>
> <x-tad-smaller> > around.  The decompiler should have said:</x-tad-smaller>
> <x-tad-smaller> ></x-tad-smaller>
> <x-tad-smaller> >     public static NameChecking aspectOf()</x-tad-smaller>
> <x-tad-smaller> >      {</x-tad-smaller>
> <x-tad-smaller> >          if(ajc$perSingletonInstance == null)</x-tad-smaller>
> <x-tad-smaller> >            throw new NoAspectBoundException(</x-tad-smaller>
> <x-tad-smaller> >              "org_codehaus_wadi_shared_NameChecking",</x-tad-smaller>
> <x-tad-smaller> >              ajc$initFailureCause);</x-tad-smaller>
> <x-tad-smaller> >            return ajc$perSingletonInstance;</x-tad-smaller>
> <x-tad-smaller> >      }</x-tad-smaller>
> <x-tad-smaller> ></x-tad-smaller>
> <x-tad-smaller> > Andy.</x-tad-smaller>
> <x-tad-smaller> ></x-tad-smaller>
Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv