Hi, Thanks for the feedback! I commented below. ----- Original Message -----

Hi all,

I agree that it was an interesting article.

...

However, since AspectJ is an extension to Java, most of oVirt developers would need to know additional programming language which puts the cost-effectiveness of this approach into question.

Actually you only need to learn some very basic stuff about pointcut definition. The rest was pure Java for anything I ever needed (before, after and around cases).

Well, it depends on both the base code and the crosscutting-concerns you develop the aspects for I guess.

From my experience with AspectJ, the very basic stuff there typically fits only for very simple crosscutting concerns. For example, in the generated aspects for the languages I developed for the crosscutting concerns in oVirt I had to use more than the basic stuff (e.g. inter-type declarations). I'm curios, where did you use AspectJ? For how many and what kind of crosscutting concerns did you use it?

DSLs are a nice thing to have, and we can start by utilizing object builders more :) Those are a kind of DSL too if nicely written. See the latest email on this list from Roman Mohr that talks about Domain Object Builders (or Spring Security Java configuration [2] to see a more complicated example of how it is used elsewhere).

Martin

[1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html [2] http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.ht...

On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs <vszocs@redhat.com> wrote:

...

Hi Arik,

thanks for sharing this, the article is very interesting!

" However, since AspectJ is an extension to Java, most of oVirt developers would need to know additional programming language which puts the cost-effectiveness of this approach into question. "

I always thought that good Java developers should be familiar with AOP concepts anyway.

I think that many are familiar with the general AOP concepts but nevertheless decide not to adopt them. Many think that AOP is useful only for simple logging and tracing or as a simplified API for byte-code manipulation (I guess that's why AspectJ is used by GWT in our build process, right?) or in its simplified form as spring-aop, because of the known drawbacks of AspectJ. Hopefully the proposed approach would change that :)

...

That said, I really like the combo of AOP with DSL (or ASL) and I agree that it can simplify handling concerns in a way that is much closer to app's domain, rather than being closer to its implementation (as with AOP).

Regards, Vojtech

----- Original Message -----

...

From: "Arik Hadas" <ahadas@redhat.com> To: "devel" <devel@ovirt.org> Sent: Monday, April 11, 2016 9:02:39 AM Subject: [ovirt-devel] oVirt-specific aspect languages

Hi All,

Last month I participated in Modularity'16, an academic conference that focuses on advanced software modularization techniques, where I presented my work in the area of domain specific aspect languages that was evaluated on oVirt.

Many have asked me to elaborate on this work, so I wrote a post that explains the idea and provides references to relevant materials that were presented in the conference, which I would like to share with you: http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/

Regards, Arik _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

----- Original Message -----

From: "Arik Hadas" <ahadas@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org> Sent: Wednesday, April 13, 2016 10:58:46 PM Subject: Re: [ovirt-devel] oVirt-specific aspect languages

Hi,

Thanks for the feedback! I commented below.

----- Original Message -----

...

Hi all,

I agree that it was an interesting article.

...

However, since AspectJ is an extension to Java, most of oVirt developers would need to know additional programming language which puts the cost-effectiveness of this approach into question.

Actually you only need to learn some very basic stuff about pointcut definition. The rest was pure Java for anything I ever needed (before, after and around cases).

Well, it depends on both the base code and the crosscutting-concerns you develop the aspects for I guess. From my experience with AspectJ, the very basic stuff there typically fits only for very simple crosscutting concerns. For example, in the generated aspects for the languages I developed for the crosscutting concerns in oVirt I had to use more than the basic stuff (e.g. inter-type declarations). I'm curios, where did you use AspectJ? For how many and what kind of crosscutting concerns did you use it?

...

DSLs are a nice thing to have, and we can start by utilizing object builders more :) Those are a kind of DSL too if nicely written. See the latest email on this list from Roman Mohr that talks about Domain Object Builders (or Spring Security Java configuration [2] to see a more complicated example of how it is used elsewhere).

Martin

[1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html [2] http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.ht...

On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs <vszocs@redhat.com> wrote:

...

Hi Arik,

thanks for sharing this, the article is very interesting!

" However, since AspectJ is an extension to Java, most of oVirt developers would need to know additional programming language which puts the cost-effectiveness of this approach into question. "

I always thought that good Java developers should be familiar with AOP concepts anyway.

I think that many are familiar with the general AOP concepts but nevertheless decide not to adopt them.

I think it comes down to two factors - experience and willingness to learn given technology. The fact that many people don't use AOP doesn't imply that AOP isn't appropriate to solve their problems. In previous company, I've used AOP with GWT to implement "command" invocation bus between client and server. The client would create an instance of a command like this: @ImplementedBy(DoSomethingWithLogic.class) class DoSomething implements Command<MyResult> { // fields to carry data go here // getters/setters go here public MyResult execute() { return null; } } and send it to server for execution. During GWT deserialization of "DoSomething" instance, an aspect would catch instantiation of "DoSomething" and replace instantiated instance with this: class DoSomethingWithLogic extends DoSomething { public MyResult execute() { // logic that executes on the server } } Many people thought of this as "hacky", I actually liked it :)

Many think that AOP is useful only for simple logging and tracing or as a simplified API for byte-code manipulation (I guess that's why AspectJ is used by GWT in our build process, right?)

GWT compiler is written in Java. It parses your code into AST, does "live" code analysis, and translates "live" code into JS. When building oVirt GWT UI, we use AOP to trick GWT compiler into thinking that all common code (shared between frontend and backend) is "live", because otherwise it would prune (cut-away) unused code and it would cause de-serialization issues back on server. That aspect can be found here: frontend/webadmin/modules/gwt-extension/ src/main/java/org/ovirt/engine/ui/gwtextension/DontPrune.java (The underlying problem is sharing code between frontend and backend which couples both sides very tightly, a much better approach is to have some API like REST in between the two.)

or in its simplified form as spring-aop, because of the known drawbacks of AspectJ. Hopefully the proposed approach would change that :)

...

...

That said, I really like the combo of AOP with DSL (or ASL) and I agree that it can simplify handling concerns in a way that is much closer to app's domain, rather than being closer to its implementation (as with AOP).

Regards, Vojtech

----- Original Message -----

...

From: "Arik Hadas" <ahadas@redhat.com> To: "devel" <devel@ovirt.org> Sent: Monday, April 11, 2016 9:02:39 AM Subject: [ovirt-devel] oVirt-specific aspect languages

Hi All,

Last month I participated in Modularity'16, an academic conference that focuses on advanced software modularization techniques, where I presented my work in the area of domain specific aspect languages that was evaluated on oVirt.

Many have asked me to elaborate on this work, so I wrote a post that explains the idea and provides references to relevant materials that were presented in the conference, which I would like to share with you: http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/

Regards, Arik _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel