Man Linux: Main Page and Category List


       ajc — compiler and bytecode weaver for the AspectJ and Java languages


       ajc [Options]  [file...  | @file...  | -argfile file... ]


       The  ajc command compiles and weaves AspectJ and Java source and .class
       files, producing .class files  compliant  with  any  Java  VM  (1.1  or
       later).   It  combines  compilation  and  bytecode weaving and supports
       incremental builds; you can also weave bytecode at run-time using "" >.

       The  arguments after the options specify the source file(s) to compile.
       To specify source classes, use -inpath (below).  Files  may  be  listed
       directly on the command line or in a file.  The -argfile file and @file
       forms are equivalent, and are interpreted as meaning all the  arguments
       listed in the specified file.

       Note:  You  must explicitly pass ajc all necessary sources.  Be sure to
       include the source not only for the aspects or pointcuts but  also  for
       any  affected  types.   Specifying  all  sources  is necessary because,
       unlike javac, ajc does not search the sourcepath for classes.   (For  a
       discussion  of  what  affected types might be required, see The AspectJ
       Programming          Guide,           Implementation           Appendix
       ../progguide/implementation.html) .

       To  specify  sources, you can list source files as arguments or use the
       options -sourceroots or -inpath.  If there are multiple sources for any
       type,  the  result is undefined since ajc has no way to determine which
       source is correct.  (This happens most often  when  users  include  the
       destination directory on the inpath and rebuild.)

       -injars JarList
                 deprecated:   since   1.2,  use  -inpath,  which  also  takes

       -inpath Path
                 Accept as source bytecode any .class files in the The  output
                 will  include  these  classes,  possibly  as  woven  with any
                 applicable aspects.  Path is a single argument  containing  a
                 list  of  paths to zip files or directories, delimited by the
                 platform-specific path delimiter.

       -aspectpath Path
                 Weave binary aspects from jar files and directories  on  path
                 into all sources.  The aspects should have been output by the
                 same version  of  the  compiler.   When  running  the  output
                 classes,  the  run  classpath  should  contain all aspectpath
                 entries.   Path,  like  classpath,  is  a   single   argument
                 containing  a  list  of  paths to jar files, delimited by the
                 platform- specific classpath delimiter.

       -argfile File
                 The file contains a line-delimited list of  arguments.   Each
                 line  in  the  file  should  contain one option, filename, or
                 argument string (e.g., a  classpath  or  inpath).   Arguments
                 read  from  the  file are inserted into the argument list for
                 the command.  Relative paths in the file are calculated  from
                 the  directory  containing  the file (not the current working
                 directory).  Comments, as in Java, start with //  and  extend
                 to  the end of the line.  Options specified in argument files
                 may override rather than extending existing option values, so
                 avoid   specifying   options   like  -classpath            in
                 argument files unlike the argument file  is  the  only  build
                 specification.   The  form  @file  is  the same as specifying
                 -argfile file.

       -outjar output.jar
                 Put output classes in zip file output.jar.

       -outxml   Generate aop.xml file  for  load-time  weaving  with  default

       -outxmlfile custom/aop.xml
                 Generate aop.xml file for load-time weaving with custom name.

                 Run   the   compiler   continuously.    After   the   initial
                 compilation,  the  compiler  will  wait to recompile until it
                 reads a newline from the standard input, and will  quit  when
                 it reads a ’q’.  It will only recompile necessary components,
                 so a recompile should be much  faster  than  doing  a  second
                 compile.  This requires -sourceroots.

       -sourceroots DirPaths
                 Find  and  build  all  .java  or  .aj  source files under any
                 directory listed in DirPaths.  DirPaths, like classpath, is a
                 single  argument  containing  a list of paths to directories,
                 delimited by  the  platform-  specific  classpath  delimiter.
                 Required by -incremental.

                 Generate a build .ajsym file into the output directory.  Used
                 for viewing crosscutting references by tools like the AspectJ

       -emacssym Generate .ajesym symbol files for emacs support (deprecated).

       -Xlint    Same as -Xlint:warning (enabled by default)

                 Set default level for messages  about  potential  programming
                 mistakes  in  crosscutting  code.   {level}  may  be  ignore,
                 warning,   or   error.     This    overrides    entries    in
                 org/aspectj/weaver/               from
                 aspectjtools.jar, but does not override levels set using  the
                 -Xlintfile option.

       -Xlintfile PropertyFile
                 Specify   properties   file   to   set  levels  for  specific
                 crosscutting messages.  PropertyFile is  a  path  to  a  Java
                 .properties  file  that  takes  the  same  property names and
                 values  as  org/aspectj/weaver/   from
                 aspectjtools.jar, which it also overrides.

       -help     Emit information on compiler options and usage

       -version  Emit the version of the AspectJ compiler

       -classpath Path
                 Specify  where  to  find  user class files.  Path is a single
                 argument  containing  a  list  of  paths  to  zip  files   or
                 directories,   delimited   by   the   platform-specific  path

       -bootclasspath Path
                 Override location  of  VM’s  bootclasspath  for  purposes  of
                 evaluating  types  when compiling.  Path is a single argument
                 containing a list of  paths  to  zip  files  or  directories,
                 delimited by the platform-specific path delimiter.

       -extdirs Path
                 Override  location of VM’s extension directories for purposes
                 of  evaluating  types  when  compiling.   Path  is  a  single
                 argument containing a list of paths to directories, delimited
                 by the platform-specific path delimiter.

       -d Directory
                 Specify where  to  place  generated  .class  files.   If  not
                 specified, Directory defaults to the current working dir.

       -target [1.1 to 1.5]
                 Specify classfile target setting (1.1 to 1.5, default is 1.2)

       -1.3      Set compliance level to 1.3  This  implies  -source  1.3  and
                 -target 1.1.

       -1.4      Set  compliance  level  to 1.4 (default) This implies -source
                 1.4 and -target 1.2.

       -1.5      Set compliance level to 1.5.  This implies  -source  1.5  and
                 -target 1.5.

       -source [1.3|1.4|1.5]
                 Toggle  assertions (1.3, 1.4, or 1.5 - default is 1.4).  When
                 using -source 1.3, an assert() statement valid under Java 1.4
                 will  result  in  a  compiler error.  When using -source 1.4,
                 treat assert as a keyword and implement assertions  according
                 to  the  1.4  language  spec.  When using -source 1.5, Java 5
                 language features are permitted.

       -nowarn   Emit no warnings (equivalent to ’-warn:none’) This  does  not
                 suppress messages generated by declare warning or Xlint.

       -warn: items
                 Emit  warnings  for any instances of the comma-delimited list
                 of questionable code (eg ’-warn:unusedLocals,deprecation’):

       constructorName        method with constructor name
       packageDefaultMethod   attempt to override package-default method
       deprecation            usage of deprecated type or member
       maskedCatchBlocks      hidden catch block
       unusedLocals           local variable never read
       unusedArguments        method argument never read
       unusedImports          import statement not used by code in file
       none                   suppress all compiler warnings

       -warn:none does not suppress messages generated by declare  warning  or

                 Same as -warn:deprecation

                 Emit no errors for unresolved imports

                 Keep  compiling after error, dumping class files with problem

                 debug attributes level, that may take three forms:

       -g         all debug info (’-g:lines,vars,source’)
       -g:none    no debug info
       -g:{items} debug info for any/all of [lines, vars, source], e.g.,

                 Preserve all  local  variables  during  code  generation  (to
                 facilitate debugging).

                 Compute reference information.

       -encoding format
                 Specify  default  source  encoding  format.   Specify  custom
                 encoding on a per file basis by suffixing each  input  source
                 file/folder name with ’[encoding]’.

       -verbose  Emit messages about accessed/processed compilation units

                 Emit messages about weaving

       -log file Specify a log file for compiler messages.

       -progress Show progress (requires -log mode).

       -time     Display speed information.

       -noExit   Do  not  call System.exit(n) at end of compilation (n=0 if no

       -repeat N Repeat  compilation  process  N  times   (typically   to   do
                 performance analysis).

                 Causes compiler to terminate before weaving

                 Causes the compiler to calculate and add the SerialVersionUID
                 field to any type implementing Serializable that is  affected
                 by  an  aspect.   The  field is calculated based on the class
                 before weaving has taken place.

                 (Experimental - deprecated as now  default)  Runs  weaver  in
                 reweavable  mode which causes it to create woven classes that
                 can be rewoven, subject to the restriction that on attempting
                 a  reweave  all the types that advised the woven type must be

                 (Experimental) do not inline around advice

       -XincrementalFile file
                 (Experimental) This works like incremental mode, but using  a
                 file  rather than standard input to control the compiler.  It
                 will recompile each time file is changed and  and  halt  when
                 file is deleted.

                 (Experimental)  Normally  it  is  an error to declare aspects
                 Serializable.  This option removes that restriction.

                 (Experimental) Create class files that can’t be  subsequently
                 rewoven by AspectJ.

       -Xajruntimelevel:1.2, ajruntimelevel:1.5
                 (Experimental) Allows code to be generated that targets a 1.2
                 or a 1.5 level AspectJ runtime (default 1.5)

   File names
       ajc accepts source files with either the .java     extension or the .aj
       extension.   We  normally  use .java for all of our files in an AspectJ
       system -- files that contain aspects as  well  as  files  that  contain
       classes.  However, if you have a need to mechanically distinguish files
       that use AspectJ’s additional functionality from those  that  are  pure
       Java we recommend using the .aj extension for those files.

       We’d  like  to discourage other means of mechanical distinction such as
       naming conventions or sub-packages in favor of the .aj     extension.

          ·  Filename conventions are hard to  enforce  and  lead  to  awkward
             names   for  your  aspects.   Instead  of  we
             recommend using Tracing.aj (or just instead.

          ·  Sub-packages move aspects out of their natural place in a  system
             and  can  create  an  artificial  need  for  privileged  aspects.
             Instead of adding a sub-package like aspects we  recommend  using
             the  .aj  extension  and  including  these files in your existing
             packages instead.

       AspectJ is a compatible extension to the Java programming language. The
       AspectJ compiler adheres to the  The Java Language Specfication, Second
       Edition (BOOK)  and  to
       the  The  Java  Virtual  Machine  Specification,  Second Edition (BOOK) and runs on any Java 2
       compatible  platform.  The  code  it  generates runs on any Java 1.1 or
       later compatible platform.  For more information on compatibility  with
       Java and with previous releases of AspectJ, see "" >.

       A simple example

       Compile two files:


       An example using -argfile/@

       To  avoid  specifying file names on the command line, list source files
       in a line-delimited text argfile.  Source file paths may be absolute or
       relative to the argfile, and may include other argfiles by @-reference.
       The following file sources.lst           contains absolute and relative
       files and @-references:

       Compile the files using either the -argfile or @ form:

       ajc -argfile sources.lst
       ajc @sources.lst

       Argfiles  are  also  supported  by  jikes and javac, so you can use the
       files in hybrid builds.  However, the support varies:

          ·  Only ajc accepts command-line options

          ·  Jikes and Javac do not accept internal @argfile references.

          ·  Jikes and Javac only accept the @file form on the command line.

       An example using -inpath and -aspectpath

       Bytecode weaving using -inpath: AspectJ  1.2  supports  weaving  .class
       files in input zip/jar files and directories.  Using input jars is like
       compiling the corresponding source files, and all binaries are  emitted
       to  output.   Although  Java-compliant  compilers  may  differ in their
       output, ajc should take as input any class  files  produced  by  javac,
       jikes,  eclipse, and, of course, ajc.  Aspects included in -inpath will
       be woven into like other .class files, and they will affect other types
       as usual.

       Aspect  libraries  using -aspectpath: AspectJ 1.1 supports weaving from
       read-only libraries containing aspects.  Like input jars,  they  affect
       all  input;  unlike  input  jars,  they  themselves are not affected or
       emitted as output.  Sources compiled with aspect libraries must be  run
       with the same aspect libraries on their classpath.

       The  following  example  builds  the  tracing example in a command-line
       environment; it creates  a  read-only  aspect  library,  compiles  some
       classes  for  use as input bytecode, and compiles the classes and other
       sources with the aspect library.

       The    tracing    example    is    in    the    AspectJ    distribution
       ({aspectj}/doc/examples/tracing).  This uses the following files:


       Below, the path separator is taken as ";", but file separators are "/".
       All commands are on one  line.   Adjust  paths  and  commands  to  your
       environment as needed.

       Setup the path, classpath, and current directory:

       cd examples
       export ajrt=../lib/aspectjrt.jar
       export CLASSPATH="$ajrt"
       export PATH="../bin:$PATH"

       Build a read-only tracing library:

       ajc -argfile tracing/tracelib.lst -outjar tracelib.jar

       Build the application with tracing in one step:

       ajc -aspectpath tracelib.jar -argfile tracing/notrace.lst -outjar tracedapp.jar

       Run the application with tracing:

       java -classpath "$ajrt;tracedapp.jar;tracelib.jar" tracing.ExampleMain

       Build the application with tracing from binaries in two steps:

          ·  (a)    Build   the   application   classes   (using   javac   for
             demonstration’s sake):

       mkdir classes
       javac -d classes tracing/*.java
       jar cfM app.jar -C classes .

          ·  (b) Build the application with tracing:

       ajc -inpath app.jar -aspectpath tracelib.jar -outjar tracedapp.jar

       Run the application with tracing (same as above):

       java -classpath "$ajrt;tracedapp.jar;tracelib.jar" tracing.ExampleMain

       Run the application without tracing:

       java -classpath "app.jar" tracing.ExampleMain

   The AspectJ compiler API
       The AspectJ compiler is implemented  completely  in  Java  and  can  be
       called  as  a Java class.  The only interface that should be considered
       public are the public  methods  in   E.g.,
       main(String[]  args) takes the the standard ajc command line arguments.
       This means that an alternative way to run the compiler is

       java [option...]  [file...]

       To  access  compiler  messages  programmatically,   use   the   methods
       setHolder(IMessageHolder     holder)    and/or    run(String[]    args,
       IMessageHolder holder).  ajc reports each message to the  holder  using
       IMessageHolder.handleMessage(..).   If  you  just  want  to collect the
       messages,  use  MessageHandler  as  your          IMessageHolder.   For
       example,  compile  and  run  the following with aspectjtools.jar on the

       import org.aspectj.bridge.*;
       import java.util.Arrays;

       public class WrapAjc {
       public static void main(String[] args) {
       Main compiler = new Main();
       MessageHandler m = new MessageHandler();, m);
       IMessage[] ms = m.getMessages(null, true);
       System.out.println("messages: " + Arrays.asList(ms));

   Stack Traces and the SourceFile attribute
       Unlike traditional java compilers, the AspectJ compiler may in  certain
       cases  generate  classfiles from multiple source files.  Unfortunately,
       the  original  Java  class  file  format  does  not  support   multiple
       SourceFile   attributes.   In  order  to  make  sure  all  source  file
       information is available, the AspectJ compiler may in some cases encode
       multiple  filenames  in  the  SourceFile  attribute.   When the Java VM
       generates stack traces, it uses this attribute to  specify  the  source

       (The  AspectJ  1.0 compiler also supports the .class file extensions of
       JSR-45.  These permit compliant debuggers (such as jdb in  Java  1.4.1)
       to  identify the right file and line even given many source files for a
       single class.  JSR-45 support is planned for ajc in AspectJ 1.1, but is
       not  in the initial release.  To get fully debuggable .class files, use
       the -XnoInline option.)

       Probably the only time you may see this format is when you  view  stack
       traces, where you may encounter traces of the format


       where instead of the usual


       format, you see

       File0;File1[Number1];File2[Number2] ... :LineNumber

       In  this  case, LineNumber is the usual offset in lines plus the "start
       line" of the actual source file.  That means you use LineNumber both to
       identify  the source file and to find the line at issue.  The number in
       [brackets] after each file tells you the virtual "start line" for  that
       file (the first file has a start of 0).

       In our example from the null pointer exception trace, the virtual start
       line is 1030.  Since the file "starts"  at  line  1000
       [1k], the LineNumber points to line 30 of

       So,  when  faced  with  such  stack  traces, the way to find the actual
       source location is to look through the list of "start line" numbers  to
       find  the one just under the shown line number.  That is the file where
       the source location can actually be found.  Then, subtract that  "start
       line"  from the shown line number to find the actual line number within
       that file.

       In a class file that comes from only a single source file, the  AspectJ
       compiler  generates  SourceFile  attributes consistent with traditional
       Java compilers.