AjcTask (iajc)

This task uses the AspectJ post-1.1 compiler ajc. The AspectJ compiler can be used like Javac to compile Java sources, but it can also compile AspectJ sources or weave binary aspects with Java bytecode. It can run in normal "batch" mode or in an "incremental" mode, where it only recompiles files it has to revisit. For more information on ajc, see The ajc Command-line Reference. Unlike Javac or the Javac Ant task, this task always compiles the specified files since aspects can apply to other (updated) files. For a workaround, see Avoiding clean compiles.

Beyond the normal ajc compiler options, this task also supports an experimental option for an incremental "tag" file, and it can copy resources from source directories or input jars to the output jar or directory.

This task is named iajc to avoid conflict with the 1.0 task ajc.

AjcTask (iajc) Options

The following tables list the supported parameters. For any parameter specified as a Path, a single path can be specified directly as an attribute, multiple paths can be specified using a nested element of the same name, and a common path can be reused by defining it as a global and passing the id to the corresponding {name}ref attribute. See Path below for more details.

Most attributes and nested elements are optional. The compiler requires that the same version of aspectjrt.jar be specified on the classpath, and that some sources be be specified (using one or more of sourceroots, injars, inpath, argfiles, and/or srcdir (with patterns)). When in incremental mode, only sourceroots may be specified.

Boolean parameters default to false unless otherwise stated.

AjcTask (iajc) options for specifying sources

AttributeDescription

argfiles, argfilesRef (Path)

An argument file contains a list of arguments read by the compiler. Each line is read into one element of the argument array and may include another argfile by reference.

sourceRoots, sourceRootsRef (Path)

Directories containing source files (ending with .java or .aj) to compile.

srcdir (Path)

Base directory of sources to compile, assuming there are nested matches. This approach uses the Ant process for matching .java files and is not compatible with incremental mode. Unless using filters to limit the sources included, use sourceroots instead.

injars, injarsRef (Path)

Deprecated - use inpath instead. Read .class files for bytecode weaving from zip files (only).

inpath, inpathRef (Path)

Read .class files for bytecode weaving from directories or zip files (like classpath).

classpath, classpathRef (Path)

The classpath used by the sources being compiled. When compiling aspects, include the same version of the aspectjrt.jar.

bootclasspath, bootclasspathRef (Path)

The bootclasspath specifies types to use instead of the invoking VM's when seeking types during compilation.

extDirs, extDirsRef (Path)

The extension directories to use instead of those in the invoking VM when seeking types during compilation.

aspectPath, aspectPathRef (Path)

Similar to classpath, aspectpath contains read-only, binary aspect libraries that are woven into sources but not included in the output. aspectpath accepts jar/zip files (but, unlike classpath, not directories).

AjcTask (iajc) options for specifying output

AttributeDescription

destDir

The directory in which to place the generated class files. Only one of destDir and outJar may be set.

outJar

The zip file in which to place the generated output class files. Only one of destDir and outJar may be set.

copyInjars

(Deprecated/ignored; ajc does this.) If true, copy all non-.class files from input jar(s) to the output jar or destination directory after the compile (or incremental compile) completes. In forked mode, this copies only after the process completes, not after incremental compiles.

sourceRootCopyFilter

When set, copy all files from the sourceroot directories to the output jar or destination directory except those specified in the filter pattern. The pattern should be compatible with an Ant fileset excludes filter; when using this, most developers pass **/CVS/*,**/*.java to exclude any CVS directories or source files. See inpathDirCopyFilter. Requires destDir or outJar.

inpathDirCopyFilter

When set, copy all files from the inpath directories to the output jar or destination directory except those specified in the filter pattern. The pattern should be compatible with an Ant fileset excludes filter; when using this, most developers pass **/CVS/*,**/*.java,**/*.class to exclude any CVS directories, source files, or unwoven .class files. (If **/*.class is not specified, it will be prepended to the filter.) See sourceRootCopyFilter. (Note that ajc itself copies all resources from input jar/zip files on the inpath.) Requires destDir or outJar.

AjcTask (iajc) options for specifying compiler behavior

AttributeDescription

fork

Run process in another VM. This gets the forking classpath either explicitly from a forkclasspath entry or by searching the task or system/Ant classpath for the first readable file with a name of the form aspectj{-}tools{.*}.jar. When forking you can specify the amount of memory used with maxmem. Fork cannot be used in incremental mode, unless using a tag file.

forkclasspath, forkclasspathRef (Path)

Specify the classpath to use for the compiler when forking.

maxmem

The maximum memory to use for the new VM when fork is true. Values should have the same form as accepted by the VM, e.g., "128m".

incremental

incremental mode: Build once, then recompile only required source files when user provides input. Requires that source files be specified only using sourceroots. Incompatible with forking.

tagfile

incremental mode: Build once, then recompile only required source files when the tag file is updated, finally exiting when tag file is deleted. Requires that source files be specified only using sourceroots.

X

Set experimental option(s), using comma-separated list of accepted options Options should not contain the leading X. Some commonly-used experimental options have their own entries. The other permitted ones (currently) are serializableAspects, incrementalFile, lazyTjp, reweavable, notReweavable, noInline, noWeave, ajruntimelevel:1.2, and ajruntimelevel:1.5. Of these, some were deprecated in AspectJ 5 (reweavable, noWeave, etc.).

Xnoweave

Experimental option to produce binaries that can only be used as input for the -injars or -inpath option. Usually aspects are compiled normally and put on the aspectpath.

AjcTask (iajc) options for specifying compiler side-effects and messages

AttributeDescription

emacssym

If true, emit .ajesym symbol files for Emacs support.

crossref

If true, emit .ajsym file into the output directory.

verbose

If true, emit compiler status messages during the compile.

Xlistfileargs

If true, emit list of file arguments during the compile (but behaves now like verbose).

version

If true, do not compile - just print AspectJ version.

help

If true, just print help for the command-line compiler.

Xlintwarnings

Same as xlint:warning: if true, set default level of all language usage messages to warning.

Xlint

Specify default level of all language usage messages to one of [error warning ignore].

XlintFile

Specify property file containing name:level associations setting level for language messages emitted during compilation. Any levels set override the default associations in org/aspectj/weaver/XLintDefault.properties.

failonerror

If true, throw BuildException to halt build if there are any compiler errors. If false, continue notwithstanding compile errors. Defaults to true.

messageHolderClass

Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor.

showWeaveInfo

If true, emit weaver messages. Defaults to false.

AjcTask (iajc) options for specifying Eclipse compiler options

AttributeDescription

nowarn

If true, same as warn:none.

deprecation

If true, same as warn:deprecation

warn

One or more comma-separated warning specifications from [constructorName packageDefaultMethod deprecation, maskedCatchBlocks unusedLocals unusedArguments, unusedImports syntheticAccess assertIdentifier].

debug

If true, same as debug:lines,vars,source

debugLevel

One or more comma-separated debug specifications from [lines vars source].

PreserveAllLocals

If true, code gen preserves all local variables (for debug purposes).

noimporterror

If true, emit no errors for unresolved imports.

referenceinfo

If true, compute reference info.

log

File to log compiler messages to.

encoding

Default source encoding format (per-file encoding not supported in Ant tasks).

proceedOnError

If true, keep compiling after errors encountered, dumping class files with problem methods.

progress

If true, emit progress (requires log).

time

If true, display speed information.

target

Specify target class file format as one of [1.1 1.2]. Defaults to 1.1 class file.

source

Set source compliance level to one of [1.3 1.4 1.5] (default is 1.4). 1.3 implies -source 1.3 and -target 1.1. 1.4 implies -source 1.4 and -target 1.2. 1.5 implies -source 1.5 and -target 1.5.

source

Set source assertion mode to one of [1.3 1.4]. Default depends on compliance mode.

AjcTask matching parameters specified as nested elements

This task forms an implicit FileSet and supports all attributes of <fileset> (dir becomes srcdir) as well as the nested <include>, <exclude>, and <patternset> elements. These can be used to specify source files. However, it is better to use sourceroots to specify source directories unless using filters to exclude some files from compilation.

AjcTask Path-like Structures

Some parameters are path-like structures containing one or more elements; these are sourceroots, argfiles, injars, inpath, classpath, bootclasspath, forkclasspath, and aspectpath. In all cases, these may be specified as nested elements, something like this:

    
    <iajc {attributes..} />
        <{name}>    
            <pathelement path="{first-location}"/>
            <pathelement path="{second-location}"/>
            ...
        <{name}>    
        ...
    </iajc>

	

As with other Path-like structures, they may be defined elsewhere and specified using the refid attribute:

    
    <path id="aspect.path">
        <pathelement path="${home}/lib/persist.jar"/>
        <pathelement path="${home}/lib/trace.jar"/>
    </path>
    ...
    <iajc {attributes..} />
        <aspectpath refid="aspect.path"/>    
        ...
    </iajc>

	

The task also supports an attribute {name}ref for each such parameter. E.g., for aspectpath:

    
    <iajc {attributes..} aspectpathref="aspect.path"/>    

	

Sample of iajc task

A minimal build script defines the task and runs it, specifying the sources:

		
<project name="simple-example" default="compile" >
  <taskdef 
      resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
    <classpath>
      <pathelement location="${home.dir}/tools/aspectj/lib/aspectjtools.jar"/>
    </classpath>
  </taskdef>

  <target name="compile" >
    <iajc sourceroots="${home.dir}/ec/project/src" 
        classpath="${home.dir}/tools/aspectj/lib/aspectjrt.jar"/> 
  </target>
</project>

		

Below is script with most everything in it. The compile process...

  1. Runs in incremental mode, recompiling when the user hits return;

  2. Reads all the source files from two directories;

  3. Reads binary .class files from input jar and directory;

  4. Uses a binary aspect library for persistence;

  5. Outputs to an application jar; and

  6. Copies resources from the source directories and binary input jar and directories to the application jar.

When this target is built, the compiler will build once and then wait for input from the user. Messages are printed as usual. When the user has quit, then this runs the application.

		
  <target name="build-test" >
    <iajc outjar="${home.dir}/output/application.jar" 
            sourceRootCopyFilter="**/CVS/*,**/*.java"
            inpathDirCopyFilter="**/CVS/*,**/*.java,**/*.class"
            incremental="true" >
      <sourceroots>
        <pathelement location="${home.dir}/ec/project/src"/>
        <pathelement location="${home.dir}/ec/project/testsrc"/>
      </sourceroots>
      <inpath>
        <pathelement location="${home.dir}/build/module.jar"/>
        <pathelement location="${home.dir}/build/binary-input"/>
      </inpath>
      <aspectpath>
        <pathelement location="${home.dir}/ec/int/persist.jar"/>
      </aspectpath>
      <classpath>
        <pathelement location="${home.dir}/tools/aspectj/lib/aspectjrt.jar"/>
      </classpath>
    </iajc>
    
    <java classname="org.smart.app.Main">
      <classpath>
        <pathelement location="${home.dir}/tools/aspectj/lib/aspectjrt.jar"/>
        <pathelement location="${home.dir}/ec/int/persist.jar"/>
        <pathelement location="${home.dir}/output/application.jar"/>
      </classpath>
    </java>
  </target>

		

For an example of a build script, see ../examples/build.xml.

Avoiding clean compiles

Unlike javac, the ajc compiler always processes all input because new aspects can apply to updated classes and vice-versa. However, in the case where no files have been updated, there is no reason to recompile sources. One way to implement that is with an explicit dependency check using the uptodate task:

		
  <target name="check.aspects.jar">
    <uptodate property="build.unnecessary" 
        targetfile="${aspects.module-jar}" >
       <srcfiles dir="${src1}" includes="**/*.aj"/>
       <srcfiles dir="${src2}/" includes="**/*.aj"/>
    </uptodate>
  </target>

  <target name="compile.aspects" depends="prepare,check.aspects.jar" 
          unless="build.unnecessary">
     <iajc ... 

		

When using this technique, be careful to verify that binary input jars are themselves up-to-date after they would have been modified by any build commands.

Programmatically handling compiler messages

Users may specify a message holder to which the compiler will pass all messages as they are generated. This will override all of the normal message printing, but does not prevent the task from failing if exceptions were thrown or if failonerror is true and the compiler detected errors in the sources.

Handling messages programmatically could be useful when using the compiler to verify code. If aspects consist of declare [error|warning], then the compiler can act to detect invariants in the code being processed. For code to compare expected and actual messages, see the AspectJ testing module (which is not included in the binary distribution).