You can clone it from:
I believe JavaMOP 3.0 works as well, but I'll assume 4.0. You can clone it from:
However, I have not tested the code in this repository. I've been using one in the Google Code repository:
svn checkout http://javamop.googlecode.com/svn/trunk/ javamop-read-only
It would be great if someone checks whether the github version works.
You can clone the repository from the Google Code page:
In the properties/ directory, you should be able to see JavaMOP specifications. Throughout this document, I'll call this properties/ directory as $JAVAMOPSPEC_DIR.
The modified AspectJ
The original AspectJ will fail to weave fop of DaCapo 9.12 with the 179 specifications. You will get the following error message, something like "code size too big". To avoid this error, I modified the AspectJ compiler. For more details, refer to the Appendix of Choonghwan Lee's thesis.
You can clone this from my repository hosted on fslwork:
git clone ssh://[your-id]@fslwork.cs.illinois.edu/home/clee83/repository/aspectj
You should be able to build it using ant. If the build procedure is successful, you will be able to see the following directory:
This directory contains all the important files:
- aspectjtools.jar: the AspectJ compiler
- aspectjweaver.jar: the load-time weaver (LTW)
- aspectjrt.jar: runtime
All of these files can be useful, but, for the purpose of generating a JavaMOP-Agent, only the LTW and runtime are necessary. Throughout this document, I'll call this lib/ directory as $ASPECTJ_DIR.
- Input: JavaMOP specifications in $JAVAMOPSPEC_DIR
- Output: RV-Monitor specifications in $RVSPEC_DIR
- Output: $ASPECT_FILE: an Aspect file in $RVSPEC_DIR
You may run JavaMOP any way that pleases you, but do not forget the -translate2RV option. I typically run as follows:
javamop -d $RVSPEC_DIR -dacapo -silent -translate2RV -n all -merge <path-to-spec1> <path-to-spec2> ... <path-to-specn>
This will generate the output files in $RVSPEC_DIR.
Both the -dacapo and -silent options are what JavaMOP 3.0 has without any explanation. They have something to do with suppressing log messages, but I'm not sure if they are effective under JavaMOP 4.0. (Qingzhou, could you shed some light on this?)
Here, <path-to-spec1> ... <path-to-specn>, where n = 179 for a thorough test, should be provided. Under UNIX systems, I guess a wildcard may work, although I have not tried.
Note: if you are running under Windows, you cannot use a wildcard. When you provide a list of full paths, you should make sure that the entire command is no longer than a certain limit, imposed by cmd.exe. You may avoid this using Powershell. I used a C# program that directly spawn a process; this is similar to calling one of exec(2) family of POSIX.
- Input: RV-Monitor specifications in $RVSPEC_DIR
- Output: $MONITORJAVA_FILE: a Java file that implements the monitoring functionality in $MONITOR_DIR
I typically run RV-Monitor as follows:
rvmonitor -d $MONITOR_DIR -dacapo -silent -n all -merge <path-to-spec1> ... <path-to-specn>
This will generate a single Java file in $MONITOR_DIR. This file implements the interface for firing events, and some data structures, such as monitors and monitor sets.
Here, specifications are, of course, RV-Monitor specifications, generated by JavaMOP.
Compile the generated Java file
- Input: $MONITORJAVA_FILE
- Output: $MONITORLIB_FILE: a .class file
You can use javac. When you compile this, you should provide the path to the RV-Monitor runtime (rvmonitorrt.jar).
Compile the generated Aspect file
- Input: $ASPECT_FILE
- Input: $BASEASPECT_FILE
- Output: $AOPAJC_FILE: an XML file
- Output: $COMPILEDASPECT_FILE
You can run the AspectJ compiler without a program, as follows:
ajc -1.6 -outxml $BASEASPECT_FILE $ASPECT_FILE
Then, ajc will generate two output files.
It is recommended to edit $AOPAJC_FILE. Right after the <aspects> tag, add the following:
<weaver options="-nowarn -Xlint:ignore"></weaver>
This will suppress less useful warning messages.