Editing AspectJ (section)

==AspectJ compatibility and implementations==
AspectJ can be implemented in many ways, including [[source-weaving]] or [[bytecode-weaving]], and directly in the [[virtual machine|virtual machine (VM)]]. In all cases, the AspectJ program becomes a valid Java program that runs in a Java VM. Classes affected by aspects are binary-compatible with unaffected classes (to remain compatible with classes compiled with the unaffected originals). Supporting multiple implementations allows the language to grow as technology changes, and being Java-compatible ensures platform availability.

Key to its success has been engineering and language decisions that make the language usable and programs deployable. The original Xerox AspectJ implementation used source weaving, which required access to source code. When Xerox contributed the code to Eclipse, AspectJ was reimplemented using the Eclipse Java compiler and a bytecode weaver based on [[BCEL]], so developers could write aspects for code in binary (.class) form. At this time the AspectJ language was restricted to support a per-class model essential for incremental compilation and load-time weaving. This made IDE integrations as responsive as their Java counterparts, and it let developers deploy aspects without altering the build process. This led to increased adoption, as AspectJ became usable for impatient Java programmers and enterprise-level deployments. Since then, the Eclipse team has increased performance and correctness, upgraded the AspectJ language to support [[Java 5]] language features like [[Generics in Java|generics]] and [[Java annotation|annotations]], and integrated annotation-style pure-java aspects from [[AspectWerkz]].

The Eclipse project supports both command-line and [[Apache Ant|Ant]] interfaces. A related Eclipse project has steadily improved the Eclipse IDE support for AspectJ (called ''AspectJ Development Tools ([[AJDT]])'') and other providers of crosscutting structure. IDE support for [[emacs]], [[NetBeans]], and [[JBuilder]] foundered when Xerox put them into open source, but support for Oracle's JDeveloper did appear. IDE support has been key to Java programmers using AspectJ and understanding crosscutting concerns.

BEA has offered limited VM support for aspect-oriented extensions, but for extensions supported in all Java VM's would require agreement through Sun's Java Community Process (see also the java.lang.instrument package available since Java SE 5 — which is a common ground for JVM load-time instrumentation).

Academic interest in the semantics and implementation of [[Aspect-oriented programming|aspect-oriented]] languages has surrounded AspectJ since its release. The leading research implementation of AspectJ is the [http://www.sable.mcgill.ca/abc/ AspectBench Compiler], or ''abc''; it supports extensions for changing the syntax and semantics of the language and forms the basis for many AOP experiments that the AspectJ team can no longer support, given its broad user base.

Many programmers discover AspectJ as an enabling technology for other projects, most notably [[Spring Framework (Java)#Aspect-oriented programming framework|Spring AOP]]. A sister Spring project, [[Spring Roo]], automatically maintains AspectJ [[mixins|inter-type declarations]] as its principal code generation output.