AspectJML 1.7.1 Readme

The full list of resolved issues in 1.7.1 (which is available since 27-Ago-2019) is listed below:

• Fixing Enum parsing.
• Experimental support for better invariant runtime checking at call site [when enabled]. For instance, if an aspect type breaks encapsulation and then breaks any invariant assertion, the instrumented runtime checks should be able to get this. All the clients should be available for compilation or bytecode weaving at least.
• First release supporting crosscutting modularity [but respecting the Java 1.7 compatibility]. This implies that default methods are not allowed and interfaces should be used in .ajml files to add properly named method advice.
• NOTE: This release compatible with Java 1.7 is much more stable [comparing to 1.8 support] when JML features [e.g. pre and postconditions] are massively used.

Notable changes

From DSL to General Purpose Aspect-Oriented Support for Java

Until release 1.7.0, AspectJML only deals with one kind of crosscutting concern, which is crosscutting contracts. Since 1.7.1/1.8.0, AspectJML now handles any kind of crosscutting concern; that is, AspectJML is now a general-purpose AOP for Java like AspectJ/@AspectJ.

Some AspectJML features to enable modular crosscutting structure:

• Key object-oriented features, such as hierarchical structure [enables hierarchical crosscutting], GOFP [good old fashined procedures], overridden etc;
• Advice in AspectJML are [plain] named methods that can be placed anywhere; they have proper metadata annotations to indicate the right dynamic crosscutting action [ex: @Before("execution(* setX(..))")];
• Advice can be declared and are activated based on the same rules that apply to Java methods [visiblity, static x instance method etc]. This makes AspectJML much more symmetric and orthogonal than AspectJ or @AspectJ;
• Open class mechanism is achieved by introducing .ajml file. A Point.ajml, for example, provides an open implementation for Point.java. Hence, in AspectJML there is no encapsulation violation since the programmer always program to the context for the desired type [Point class in this case];
• There is no notion of Aspects in AspectJML; that is, unlike AspectJ or @AspectJ, AspectJML does not have a type plain the role of an aspect.
• AspectJML does support multidimensional separation of concerns using slices at .ajml files. For example, for Point.java, we can have PointDisplay.ajml and PointBoundsChecking.ajml. Once compiled, we get only one type Point.class;
• Instance and Class/Static level advising;
• The AspectJML/ajmlc compiler generates [via option enabled] a build.ajmlsym that provides a parsed and much more interesting crossreferencing than the one provided by the standard AspectJ/ajc compiler. This crossref file does provide crossref information for AspectJ programs as well and is important when AJDT plugin with visual crossrefs are missing or not available;
• An overview of AspectJML is under the way together and should be announced shortly as a draft or TR at least;
• The key ideas can be found in the AOP Reloaded paper;
• You are very welcome to have fun with AOP/AspectJML online, try it now!

Enhancement of Java 5+ features

Since AspectJML is based on the old JML2 infrastructure of JML, which has no support for Java features above 1.4, the enhancement to support Java 1.5 or above is continuous. This time AspectJML was enhanced in Enum types again and speed up of Java 5+ parsing [as much as possible].