More IDEs See below for a list of available AspectJ downloads. You probably want one of: the most recent development build , the most recent milestone build , or the latest stable release.
Installation instructions and more information on IDE support can be found at the bottom of this page. Note: All code, documentation and other files in the 1. On many systems they can be run directly by selecting "Open this file from its current location" or by double-clicking the downloaded file. If you download the. Breadcrumbs Home Projects aspectj Downloads. Downloads The AspectJ compiler produces programs for any version of the Java platform jdk1. Downloads See below for a list of available AspectJ downloads.
Only download this version if you are prepared to work with a pre-release compiler. This is the same as the Java launch configuration except that it automatically adds aspectpath entries to the runtime classpath. What if you had a project containing Java code, in either source form or in a JAR file, to which you wanted to apply aspects? If you needed to keep the aspects separate from the project you could leave it as a Java project and create an AspectJ project to do the weaving in.
When doing binary weaving like this you no longer have any source code markers to show where advice is having an effect. A compiler option is helpful here: From the Other tab of the AspectJ Compiler settings for the AspectJ project or from the global preferences , select the Output weaving info messages to problems view option. Now, whenever the project is built the Problems view will show information entries to indicate which types have been woven.
So far we have seen compile-time weaving , which is where the AspectJ weaving process takes place as the source code is compiled. When using aspects from other projects using the aspect path setting we were using binary weaving , which is when existing class files or JAR files are woven. A third possibility is load-time weaving , which is binary weaving that is deferred until a class is actually loaded by a class loader. Consider an example workspace with an AspectJ project containing aspects called MyAspects, and a second project called WeaveMe, which can be either a regular Java project or an AspectJ project.
With no aspect path or in-path setting, no weaving will take place at development time. Instead we will use the load-time weaving capabilities of AspectJ 5 to perform the weaving as the application is launched.
Load-time weaving is configured by AJDT using a launch configuration. There are a number of settings to be made from this launch configuration. Firstly fill in the Main tab with the project and class containing the main method in your application, just as with regular Java application launch configurations. The Add Projects Pressing Run causes the application to be launched as it would be normally, with the additional step of weaving any aspects from the load-time weaving aspectpath into classes as they are loaded.
Figure 5. Launch configuration for Load-Time Weaving. A useful option to put in here is a weaver flag to cause messages to be output to the console to show which classes are woven with which aspects as they are loaded:. The concept of reusable aspect libraries is a very powerful one. Let's say you have developed an aspect that you think might be applicable to other projects.
You could then generalize the aspect and separate it out into its own project to form a library. Typically an aspect in a library would define the appropriate behaviour, which could then be tailored to a specific purpose as required. This would most likely involve an abstract aspect with an abstract pointcut. The project using the aspect would then extend it with a pointcut defining the appropriate scope for the aspect to apply to.
If the project using the aspect library contained a concrete version of any required abstract aspects, you could link the two projects simply by adding the library project to the Projects tab from the Java Build Path properties page. As the concrete aspect is local to the project, regular classpath lookup would be sufficient to resolve the super-aspect. Notice also that the editor markers and Cross References view show the source of the advice as the abstract super-aspect.
This is correct because that's where the advice is; however in this situation the pointcut in the concrete aspect is controlling the application of advice, and it is that which is often of interest. Given the potential of reusable aspect libraries, you can expect the general support in this area to increase in later releases of AJDT. Simply take a plug-in project and right-click to convert it to an AspectJ project in the same way you would a regular Java project.
You will then be prompted to add a dependency on the org. AspectJ programs have a runtime dependency on the aspectjrt. After adding this dependency to your project, you can go ahead and start using aspects in the further development of your plug-in. Right-click on a plugin. The generated build. When it comes to deployment, there are also several Export wizards available, so you can export Deployable plug-ins and fragments with AspectJ support and export an Eclipse product with AspectJ support.
These wizards operate the same as the regular versions, except they use the AspectJ compiler and correctly treat. As you saw earlier, markers in the AspectJ editor and Cross References view clearly show you the nature of crosscutting on a per-file basis. What you don't get from these features alone is a good overview of how widespread the concern is -- whether it cuts across the entire project or just a couple of packages, for example.
For this type of perspective, you'll use the Visualiser. The easiest way to bring up the Visualiser is to switch to the Aspect Visualization perspective, which presents a visual representation of the selected project consisting of a column for each source file, with a height proportional to the number of lines in the source file.
Stripes are then painted on the columns at the appropriate positions to represent the source locations where advice is having an effect or potentially having an effect, in the case of an additional runtime test. The colour of each stripe corresponds to the aspect containing that advice. You can see this in the screenshot in Figure Figure 6. The Visualiser. As you can see, there is the main Visualiser view and a second Visualiser Menu view, which lists the aspects being displayed.
You can change the colours used to represent different aspects from this list, or you can de-select aspects to remove them from the visualization. For example, you may want to remove a pervasive logging aspect that is obscuring other aspects.
You can use controls on the toolbar of the Visualiser view to zoom the view in and out, to fit the contents to the view subject to certain minimum sizes , to only show columns that are affected by advice non-affected columns are otherwise shown in grey , and to switch the grouping level from class view to package view where all the classes in a package are grouped into a single column.
Finally, you can use a drop-down menu to access other options such as the preference page, where you can further customize the rendering. In addition to showing the effects of advice, the visualization includes the locations matched by AspectJ "declare error" and "declare warning" statements.
These can be toggled on or off from the Visualiser Menu toolbar. The Visualiser is designed to cope with large projects, although quite a lot of processing is required to determine the size of every class and to render the visualization. As available graphics memory is usually far more limited than general memory, the rendering process has been optimized to keep the use of graphics memory to a minimum.
The columns are rendered as they are required, so scrolling the view for the first time is not usually as smooth as it is on subsequent occasions. General memory is used to cache the image data, unless it is in short supply, in which case the image data is regenerated each time. This means that larger projects can still be shown, but with limited memory the scrolling is not as responsive.
The Visualiser supports a selection mechanism, which can be operated via the mouse or the keyboard, to select columns, classes, or stripes. Activating a selection by double-clicking with the mouse, or pressing the spacebar causes the corresponding item to be opened in the editor. It is also worth noting that the Visualiser is actually a completely general-purpose component that can be tailored to visualize anything, from Eclipse markers to Google search results.
As well as providing custom data to the Visualiser, you can also customize the drawing style of the columns and the colours used for the stripes. During the lifetime of a project classes and methods are likely to be added, removed, and renamed, as the code is refactored, bugs are fixed, and new features are implemented.
Managing this change with large projects can be challenging, particularly when there is a great deal of crosscutting functionality. Capturing this functionality with aspects improves the situation by collecting the relevant code together, instead of it being scattered across the codebase.
Pointcuts are then used to define the join points at which advice in the aspect applies. In the face of the above changes over time, however, even this set of matching locations can change unexpectedly. The first approach to managing this issue is to develop robust pointcuts from the start. A well-built pointcut is less likely to stop matching the required locations after changes are made to the code.
This matches calls to update methods with a single-integer parameter. But if someone later adds an extra parameter to the method, the pointcut will no longer match. Even with these precautions, some types of changes can cause problems for the most robust of pointcuts; for example, in the above case the method's parameters could be changed such that the integer of interest was no longer the first parameter.
Another type of change might cause a pointcut to start matching in more places than was required. The Crosscutting Comparison functionality in AJDT was developed precisely to assist you in handling these types of changes to your code.
Crosscutting Comparisons allows you to take a snapshot of the crosscutting relationships in your project and then compare the snapshot with relationships present in a later version of the project.
You will then be prompted for a filename to save the relationship map into. These files have the. For example, when you release a particular version of your project, you might save the crosscutting relationships for that release, in order to use them as a point of reference when developing the next release.
Once you have one or more crosscutting map files in your project, you can perform a comparison. Two such files can be compared with each other, or you can compare the relationships in one file against the relationships present in the current build.
These two comparison options are available by selecting one or two map files in the package explorer, then right-clicking and selecting the appropriate option from the context menu. The results of the comparison are then displayed in a new view, as shown in Figure Figure 7. Crosscutting Comparison view. The view shows crosscutting relationships that have been added since the first map file was recorded, as well as ones that have been removed; that is, are not present in the second map file or in the current build.
You can double-click the source and target elements to open them in the editor except for ones that no longer exist, of course. There is a filter button on the toolbar to restrict the set of relationships that are shown. The default is to only show relationships in one direction, such as "advises", instead of also "advised by". Note that if you have selected to compare a map file with the current build, the comparison will be re-run whenever a build occurs. This gives you an ongoing view of what has changed since the map file was created, which can be very useful when refactoring code in a project.
In addition to project-level comparisons, it is also possible to compare two elements within the same project. The Propagate Up button on the view's toolbar raises the granularity of the comparison to the level of enclosing methods. This means that advice matching the execution of a method can be considered the same as a statement within the same method which is matched by a declare warning statement.
This can be particularly useful when refactoring code to use aspects, as a declare warning statement might be used to identify behaviour that is going to be handled by advice. The comparison functionality can then be used to check that all of the locations matched by the declare statement are covered by the matching locations for the advice.
This offers a great chance to demonstrate some possible uses of aspects and also means that new versions of AJDT get a lot of manual testing in addition to many automated tests. AJDT is implemented by a number of AspectJ-enabled plug-ins, with a total of around , lines of code.
Aspects are used to implement a number of crosscutting concerns:. In addition to providing an Eclipse interface to the incremental AspectJ compiler, AJDT provides a sophisticated editor for AspectJ source code, multiple approaches for visualising and navigating crosscutting structure, and close integration with other parts of Eclipse to facilitate the development of AspectJ-enabled plugins, products and RCP applications.
0コメント