Re: [aspectj-users] AspectJ vs PostSharp?

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hi,

> I dare to guess that under the hood, AspectJ contains a logic similar to> that of PostSharp.Core. There should be an object model describing the JVM> byte code, should it? Assuming I am right, is it possible to take advantage> of that model to extend the capabilities exposed through the current high> level declarative AspectJ language? Like having a door into the low level> AspectJ API, much like PostSharp.Core does.
Yep internally AspectJ is monkeying with the bytecode.  Using a
bytecode library to work it at about the level you'd see in assembly
language (so loads, stores, adds, etc). The ability to participate in
this process and modify the bytecode directly is not currently exposed
to the end user.  You can write advice (today) that would generate
code (via a bytecode library) on the fly that could be called from
that advice.

There is no plugin mechanism that lets you go further though, by, for
example, supplying a plugin to the weaver process that could perform
arbitrary bytecode changes before/after AspectJ does its thing.  What
would you want to do?

We also have to keep in mind that AspectJ was intended as an AOP
language and take care to add things that make sense along those lines
rather than becoming a kitchen sink: "'if we can feasibly do that, we
will do that".

cheers,
Andy

On 14 December 2011 11:17, Mark <mark.kharitonov@xxxxxxxxx> wrote:
> While learning AspectJ I am constantly comparing it against PostSharp - the
> aspect framework I used in .NET. Let me give a very brief and somewhat
> simplified overview of how PostSharp works (just in case). This way it would
> be easier for me to ask the question.
>
> 1. .NET code is compiled as usual and produces dll or exe.
> 2. A dedicated PostSharp msbuild task kicks in, which reads the dll or exe
> produced in (1), parses the MSIL byte code to create the byte code object
> model.
> 3. Registered user aspects are invoked. PostSharp.Core exposes the MSIL byte
> code object model through a dedicated API, which lets the aspect to
> manipulate the model as it pleases (including, but not limited to, creating
> new methods and filling in the method instructions). Implementing
> crosscutting concerns is done by registering advices with the interesting
> join points (similar to those of AspectJ).
> 4. Next, the PostSharp.Core engine travels the object model to create the
> corresponding .il file. During the traversal it invokes the advices
> registered by the aspects in (3).
> 5. Finally, MSIL assembler is called to compile the .il file from (4) into
> the respective dll or exe.
>
> This is roughly how the low level PostSharp.Core engine works. It is low
> level, because the advice is responsible to inject the MSIL byte code,
> meaning the advice author must be comfortable with the MSIL byte code
> language.
>
> (As a side note, PostSharp comes with a higher level API, called
> PostSharp.Laos, but in order to have efficient logging, I had to work at the
> PostSharp.Core level)
>
> Anyway, I am nearing the punchline of my question. The aspect code (written
> in C# in my case) is invoked during the compilation of the subject project
> and has a complete access to all the metadata of that project. Everything
> available to the compiler is made available to the aspect code through the
> PostSharp.Core API.
>
> It so seems to me, that AspectJ compares to PostSharp.Core as the C++
> compares to the assembly language. Coding in AspectJ creates a code to be
> run during the compilation, but that code is specified declaratively using
> special high level syntax.
>
> I dare to guess that under the hood, AspectJ contains a logic similar to
> that of PostSharp.Core. There should be an object model describing the JVM
> byte code, should it? Assuming I am right, is it possible to take advantage
> of that model to extend the capabilities exposed through the current high
> level declarative AspectJ language? Like having a door into the low level
> AspectJ API, much like PostSharp.Core does.
>
> --
> View this message in context: http://aspectj.2085585.n4.nabble.com/AspectJ-vs-PostSharp-tp4196604p4196604.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users