School of computer science and informatics, cardiff university

Programming Experience

The most important feature of a language is its usability and the time that is required to acquaint programmers with the new concepts introduced, as well as the identification of crosscutting concerns. Gregor Kiczales [19] compared the mental model of a Java program and an AspectJ program, which is probably the hardest part of the paradigm that needs comprehension. Since AspectJ is just an extension to Java, the learning curve was not too extreme since most of the code from the Java system developed could be transferred without any changes, although it does present a new way of visualizing the design structure of a program. In my experience, it took a few weeks to get to grips with the language, but once some smaller programs were developed and through the help of facilities available with Eclipse, which will be discussed later, the logic behind the aspect weaving process became clearer. If you were to interpolate this to a larger group of programmers, their ability to comprehend the new paradigm would obviously depend on their abilities as a programmer, but by reading into the subject it should not be too difficult to understand and use in larger systems.

The identification of aspects can be affected by both the size and scope of a given program. The experience of this stage can differ depending on whether the aspects are being added to an existing system, as seen by this experiment, or the program is being designed from scratch. From my experience, it was difficult to move from an object-oriented view of the program to an aspect view at first, but after identifying some key concerns such as exception handling and validation, the design process became much simpler. The fact that the Java code was already developed helped as a reference to the required functionality, but the analysis may have differed if it was the AspectJ code designed first without any base code to draw from. That is an area which would still need some exploration.

One determining factor for usability is the syntax of the language and its expressiveness. Much of the syntax in AspectJ does have the feel of Java, such as the need for packaging and importing other classes, as well as the aspect definition being similar to a class definition. The syntax which would be most foreign to an outsider would be the pointcut designators, defining which join points at which advice will be executed. Bonér [2] described the syntax of AspectJ as having orthogonality and credits its expressiveness, indicated by the wide range of designators available and their descriptiveness. The naming of these designators has also helped comprehension on my part, aided by other sources, although some restrictions on their use were not as clear until implementation, such as the blocking of advice with the handler(…) designator unless it is before advice. In addition, the availability of wildcards allows for reuse as well as setting precedence for future modifications, such as the naming of methods. Wildcards should be used with caution, however, which was experienced in this thesis when declaring parents. After declaring any class with the suffix “...Listener” would require implementation of “ActionListener” using a wildcard, an error appeared in the code with a name change required. This was not an issue with the program involved, but a larger system would be more susceptible to unintended errors, wasting valuable resources.

As mentioned previously, the tool support given by Eclipse aided comprehension during development, although there were some issues as well. Starting with the positives, the markers displayed to indicate use of advice showed the weaving process clearly and concisely. On top of this, the use of red lines to indicate errors continues from the Java editor, although because the weaving process takes longer to compile, the errors took a few seconds longer to appear and were not instantaneously displayed, often requiring the user to save their work before any old errors are removed, which slowed down development. The biggest problem encountered was not the actual coding, but the exporting of a runnable JAR file after completion of the AspectJ project. The code was originally developed using Eclipse Juno; however the required libraries for weaving were incorrectly installed, even after a re-install took place. Upon researching on the internet for solutions, the AJDT plugin was optimised for more recent releases and other users commented on their problems, which meant that I had to download Eclipse Kepler [41], the latest version available, and then import the projects from one to the other. This did waste some time and would be more problematic if more than one person was coding on the same program. When the exporting did function correctly, there was a negligible difference, if any, between the compilation times of both systems.

Software’s requirements can change over time, and the ability to modify the existing code or integrate addition features needs to keep the use of resources such as time to a minimum. This thesis required integration over time because of the choice of methodology based on developing aspects separately. Apart from needing to remove redundancy from the base code, very little modification was required. Pointcuts could also be modified to include addition join points through the use of logical operators. For example, the validation aspect did not deal with one method involving an integer parameter which had been removed from the original code, and just by adding an additional logical constraint the modification was very simple. AspectJ’s concept of obliviousness allows for this ease of integration, as neither the base or aspect code know what the other does.

Another key area in development is testing, especially for using agile software development. Existing testing methods used with object-oriented languages were compatible with AspectJ during development, as suggested by Grekova [11]. Since the output of the weaving process is Java bytecode, the JUnit tests performed previously were usable and the program still passed all of them. For these reasons, a conclusion can be reached that object-oriented testing processes are transferable, if used in the correct way. The experience of the testing process for both systems was quite similar, so there are transferable skills.

Once a given program has been developed, the performance of the executed code needs to be measured, whilst minimising overheads. Before measuring the time taken to load the runnable JAR files, and display the login screen, it was safe to assume that there should not be a major difference between compilation times, if any, since both are in Java bytecode. The following table displays the times recorded for the loading of the JAR files from the desktop. To ensure a fair outcome, the measurements were collected three times, with an average taken as the final result. The times were measured using a stopwatch. One point to make is that the code creates a log file as part of its initialisation, slowing down the loading time. This file was already created; the program only puts a lock on editing the file whilst in use.

As has been proved with the test plan, in Appendix A, both systems had the same functionality and interface layout. This shows the ability to match the object-oriented approach in terms of the end product, which would be encouraging to those looking at using AspectJ, or another aspect-oriented language, in the future.