Re: [aspectj-dev] AspectJ

[Andy Clement <andrew.clement@xxxxxxxxx>]

I don't fully understand some of the questions but let me talk around them, maybe I'll answer them by accident ;)

- How did you and your team tackle the choice to change the version of Java supported?

AspectJ has always been version chasing Java. As developers look to use new Java versions (for various reasons, sometimes related to new features, sometimes just for better performance/etc) they need AspectJ to compile that level of java and recognize (for matching/weaving) the byte code for that level of Java. So we try to release a compatible version of AspectJ soon after a version of Java comes out. This has become more challenging with the new faster release cycle of Java. Although the important versions are the long term supported levels (8/11) developers still want to play with the other versions so we try to keep up.  What particularly makes this difficult is that we run a modified form of the JDT compiler where the grammar has been extended to include AspectJ constructs (pointcuts/advice/intertype declarations). Merging the grammars, regenerating the parser, upgrading to a latest JDT that supports the latest Java is painful. Something that used to be done very occasionally (due to the slow Java release cycle) now has to be done much more regularly.

- Which factors did you take into account when doing this?

The key factor to be taken into account is the release schedule of Java. The secondary factor is whether eclipse JDT fully supports that version yet - they are usually pretty good about having support around the same time. Once JDT supports that level of Java we can do the integration work to bring that JDT version into AspectJ.

- Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with?

For each Java version you'll typically see a ticket like this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533790 - but there isn't much detail in there...  There are no discussions about whether to support it or if the features of the new version of Java justify the work, we have to support it. Having said that there can be new features that impact how AspectJ behaves and need to be taken into account, for example when default methods came into interfaces, or modules came into existence, but again there is no question of doing the work, we have to. There *are* features we should handle even better, for example https://bugs.eclipse.org/bugs/show_bug.cgi?id=471347 which concerns point cuts matching lambda expressions, which should be done, but there is no resource to work on it (and it only gets requested periodically, there aren't a thousand users banging on the door for it).

- Why were no explicit changes made to the interface to support lambda expressions?

Not sure what you mean by 'interface' - do you mean the AspectJ runtime? I can't immediately think of what we'd mark as a functional interface. AspectJ supports the user writing lambda expressions by virtue of being based on JDT. The only piece of the puzzle not addressed is what I referred to in the previous question. If you switch from anonymous inner classes to lambda expressions your point cuts won't work correctly against the invoke dynamic byte codes right now - if that is what you are asking about, the reason it isn't done is resource.

- Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported?

Again, not sure what you mean. Where do you think support is missing? I think AspectJ will proceed as-is for the foreseeable future, chasing Java versions and picking up those features via JDT improvements. 

Andy

On Mon, 12 Aug 2019 at 07:43, Anand Sawant <anandsaw@xxxxxxxxx> wrote:

Dear Developers,

we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8âs lambdas. During the course of our investigation, we manually inspected AspectJ’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings.

Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization.
Our analysis showed that though AspectJ 1.9.4 did not explicitly introduce support for functional interfaces (for e.g. by using the @FunctionalInterface annotation). We noticed that the API does provide compatibility with Java 8+ features, including lambda expressions (since the APIs build platform is now on JDK 11). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API.

In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this?
- How did you and your team tackle the choice to change the version of Java supported?
- Which factors did you take into account when doing this?
- Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with?
- Why were no explicit changes made to the interface to support lambda expressions?
- Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported?

In the interest of science, we thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know!

 

Regards,

Anand Sawant.

 

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/aspectj-dev