Re: AspectJ was judged an impractical dependency

[Michael Schnell]

Hi,

 

in an old discussion there is a statement "AspectJ was judged an impractical dependency".

 

Why that? Looking at the source I get the Impression you pretty much re-programmed stuff that would have been very easy with AspectJ.

Another drawback is, that it looks like you only support "static weaving" (The checking code is always compiled into the target JAR and only runtime checking can be enabled/disabled).

 

Cheers,

Michael

[Nhat Minh Lê]

On Sat, Jun 22, 2013 at 8:11 AM, Michael Schnell
<reg.goo...@future-invent.de> wrote:
> Hi,

Hi,

>
> in an old discussion there is a statement "AspectJ was judged an impractical
> dependency".
>
> Why that? Looking at the source I get the Impression you pretty much

To be honest, I don't remember exactly now; stuff has been lost to
time. What I can say fore sure is that at the time, the project was
developped at Google, and we had ASM in the Google tree, but not
AspectJ, so there you go.

> re-programmed stuff that would have been very easy with AspectJ.

As far as I know, most of the Cofoja code deals with stuff like
inheritance and proper propagation and enforcement of contracts
(believe it or not, it's quite more involved than one would think).
Those things are not, to my knowledge, made any easier with AspectJ.
Other contract frameworks exist that use AspectJ and I remember at
least one of them listed inheritance as a major feature that needed to
be coded on top of AspectJ.

The only thing I think AspectJ would help with is code generation and
weaving, both of which are handled by ASM for us, so it wouldn't be a
big gain. Besides, we have very specific needs for "hooks" (I think
the AOP community uses the term "join point"), so there's absolutely
no need to have a complex pattern matching system to decide where to
weave, especially if that system doesn't natively support our
inheritance patterns.

> Another drawback is, that it looks like you only support "static weaving"
> (The checking code is always compiled into the target JAR and only runtime
> checking can be enabled/disabled).

We support dynamic weaving as the preferred method to inject
contracts. It's done through a Java agent, just like AspectJ does.

Hope that helped shed some light on the internals of Cofoja,
Nhat

>
> Cheers,
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups
> "cofoja" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cofoja+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>