Aspect Weaver¶
A software utility that selects program sites and integrates separately specified aspect behavior or structure into eligible code or running applications.
Core Idea¶
An aspect weaver is a software utility that can integrate a separately specified concern into selected sites of a base program or running application. The utility is a capacity: it may be configured and ready even when no particular weave is occurring. An invocation selects eligible sites and makes the concern operative; that invocation is the weaving operation, while its altered class, generated source, or changed running behavior is a result. AspectJ documents compile-time, post-compile, and load-time routes for its class-file weaver.[1] The AspectC++ utility instead transforms supported AspectC++ source into ordinary C++ for a later compiler.[2]
The stable relation is available tool → base plus separate concern → selected binding sites → operative integrated effect. It does not require every weaver to emit a file or to work at the same phase. The archived PROSE project describes extensions deployed into a running Java application, whose effect can be reordered or withdrawn.[3]
Structural Signature¶
Five roles define the tool's external contract:
- Reusable callable capacity. An implementation or platform is available to perform eligible integrations, apart from one completed event. AspectJ offers an enabled loader or agent route; AspectC++ supplies the callable source front end.[1][2]
- Base and separately specified concern intake. It takes base source, classes, or running behavior together with an aspect, advice, introduction, or extension. In AspectJ, the concern may be supplied as source or binary and must be visible to the weaving class loader for load-time use.[1]
- Concern-to-site selection and binding. Pointcuts, type patterns, or equivalent rules identify supported places where the concern can apply. AspectJ distinguishes join points and advice from inter-type declarations; an introduction need not be before-or-after advice.[4]
- Integration capability. The utility can actually carry out source, class-file, load-time, or running-program integration within its supported reach. AspectC++ describes a scanner, parser, join-point planning, and source generation in its front end.[2]
- Operative effect contract. Successful use makes the selected addition active. A woven class file and generated C++ source are two documented forms; PROSE's running extension shows why a durable emitted file is not required of the kind.[1][2][3]
If selection is removed, the tool may still translate or execute code but no longer binds a separate concern to eligible sites. If integration is removed, it becomes a matcher or checker. If reusable capacity is removed, what remains is one historical weave rather than the weaver.
What It Is Not¶
A weaver is not identical to aspect weaving, the event it performs. It is also not every compiler: the ordinary compiler contract does not imply an independently specified concern and a selector that attaches it to program sites. AspectJ's compiler can qualify because it includes the weaving contract, not merely because it compiles.[1][5]
A pointcut linter that reports candidate join points without integrating advice or an introduction stops before the tool's operative effect. A hardcoded, one-location text splice lacks the reusable concern-to-site selection contract. A program executing already woven advice is downstream of the tool; the advice may run at a selected join point long after the integration step. AspectJ documents advice execution and structural declarations as distinct language facilities.[4]
Scope of Application¶
AspectJ's class-file route can weave as source is compiled, after compilation, or while a loader defines a class. Its load-time route depends on configured aspects, type patterns, and class-loader visibility. The AspectJ guide explicitly distinguishes it from altering classes that are already defined in a JVM without reload.[1]
AspectC++ applies its own C++ pointcut and introduction language in a source-to-source front end; its output is compiled by a conventional C++ compiler. The authors present both a reusable Observer construction and an error-handling construction as source-level examples.[2]
The archived PROSE account describes a dynamic Java platform with several historical interception mechanisms, including debugger, JIT-hook, and bytecode approaches. They are alternatives across versions, not simultaneous ingredients of every installation.[3] The original 2002 paper's accessible metadata and abstract identify a dynamic-weaving research aim; they do not establish its detailed implementation or benchmark results here.[6]
Clarity¶
Four things can be confused: tool, invocation, woven result, and later execution. The tool offers a selector and integration path. A particular invocation applies them to eligible inputs. The result is a changed source, class, or running program. Advice execution then occurs according to the program's control flow. In AspectJ, advice and inter-type declarations are different ways a concern can take effect; not every selected addition is a before-or-after action.[4]
“At load time” is also precise. AspectJ can weave a class while it is being defined by a weaving loader, subject to visibility requirements; this does not by itself prove modification of a class already defined to that JVM.[1] A dynamic extension platform is a different documented variant rather than a stronger reading of the AspectJ limit.[3]
Manages Complexity¶
The tool separates concern specification from each base location that may receive its effect. A pointcut or type pattern names eligible sites, and the integration mechanism applies the declared addition under the selected language's rules. AspectC++'s Reusable Observer example maps one observer concern to selected C++ classes and state-change methods using introductions and after advice.[2]
That separation does not eliminate integration conditions. An AspectJ load-time configuration needs the weaving loader to see the aspects, while the AspectC++ front end must parse supported C++ translation units and aspect headers.[1][2] A diagnosis should retain the concern, selector, phase, target reach, and observed effect, rather than call every failure “weaving failed.”
Abstract Reasoning¶
Suppose a declared concern has no visible effect. Ask in order: Was an integration-capable utility available? Did it receive the base and separate concern? Did the selector include the intended site? Was that site eligible at the implementation's phase? Did an integrated result become operative? This sequence follows the five-role contract. AspectJ's loader visibility and pre-definition restrictions make the fourth question concrete.[1]
The same diagnostic can identify a category error. If a tool reports matching sites but never changes code or running behavior, it is a selector analysis tool. If a generated program has the expected behavior but its weaving utility is no longer present, the program is a result, not evidence that the result itself is a weaver.
Knowledge Transfer¶
Within aspect-oriented tooling, transfer the five questions across class-file, C++ source, and dynamic-extension implementations. Keep each tool's supported language, site rules, and integration phase attached to the answer. AspectJ's class-file output, AspectC++'s generated C++, and PROSE's reported running behavior have different carriers.[1][2][3]
Outside this field, a compiler plugin or policy-injection framework can be compared by the same questions, but resemblance does not establish that it is an aspect weaver. The additional aspect-to-site binding and operative integration contract must be shown for that implementation. No performance ranking transfers from these examples to other tools.
Examples¶
Canonical: AspectJ load-time class weaving¶
A configured AspectJ weaving agent or class loader supplies the reusable capacity. Base class files and visible configured aspects are the two inputs; type patterns and pointcuts limit which classes and join points are eligible. During class definition, the weaver emits woven class files whose advice or introductions become operative. The guide's class-loader requirements and already-defined-class limit bound this case.[1][4]
Mapped back: callable loader/agent (capacity); classes plus aspects (intake); patterns and pointcuts (selection); pre-definition weave (integration); loaded woven class (effect). It does not claim that this AspectJ route rewrites an already loaded class.
Applied: AspectC++ Reusable Observer¶
In the authors' worked example, the ac++ front end takes C++ translation units with aspect definitions, uses pointcuts to select subject and observer classes and a state-change method, and generates ordinary C++ with observer roles and notification behavior. Base-class introductions and after advice supply different parts of the integrated concern. This is a documented example, not an independently reproduced execution.[2]
Mapped back: ac++ (capacity); C++ program plus aspect headers (intake); Observer pointcuts (selection); source generation (integration); generated C++ compiled onward with notification behavior (effect).
Dynamic boundary: PROSE¶
The ETH project account describes a platform that can deploy a Java-class extension into a running application, track affected execution points, and selectively retract the extension. The account retrospectively describes different debugger, JIT, and bytecode versions; the original AOSD paper's available abstract is narrower than a verified full methods section.[3][6]
Mapped back: project platform (capacity); running application plus extension (intake); affected execution points (selection); version-dependent runtime mechanism (integration); altered running behavior (effect). This bounded case shows why an emitted source file is optional, while leaving numerical overhead and exact original-paper mechanisms unclaimed.
Structural Tensions¶
T1: Early integration versus later adaptation. A source or class-file front end can settle the addition before execution; a dynamic platform can defer some changes until an application is running. Choosing the early side makes the integrated artifact inspectable before use but cannot promise arbitrary post-definition adaptation. Choosing the later side allows some active-program changes but faces version-specific interception and visibility conditions. AspectJ's load-time boundary and PROSE's runtime account locate the difference.[1][3] Diagnostic: At which phase must eligible sites be fixed, and what changes remain possible afterward?
T2: Broad selector expressiveness versus bounded context cost. Rich pointcuts and join-point context can name reusable crosscutting sites; obtaining dynamic context or performing runtime interception can require additional machinery. Asking for richer context may support a concern's selection or advice but raises implementation work; restricting context may reduce that work but can make the concern inexpressible. AspectJ distinguishes a static join-point part from fuller dynamic context, and AspectC++ discusses requested join-point state and inlining as overhead factors.[4][2] Neither source licenses a universal percentage or an all-tools speed ordering. Diagnostic: Which selector and context fields are actually needed at this implementation's eligible sites?
T3: Tool autonomy versus reduction to the operation. The utility must be more than one performed weave because its callable selection-and-integration capacity remains describable before any invocation. Reducing it to the event loses idle but available weavers; treating it as wholly autonomous loses the required effect contract, leaving a checker or generic translator. A performed weave, program transformation, or compiler route may be involved when the utility runs, but none of those events or narrower routes by itself supplies the full reusable tool capacity across the documented variants. Diagnostic: Is the object an available capability, an invocation of it, or the result of an invocation?
Structural–Framed Character¶
The entities are a base program, a separately specified concern, eligible sites, and an available integration utility. Their relation is selector-guided: the utility can bind the concern to supported sites when invoked. The frame is a software build, class-loading, or runtime adaptation environment. Variation lies in source versus class-file versus running-program carriers and in which sites each implementation can reach.
The identity is mainly structural within a human-designed software practice. Its test does not ask whether the tool is good or whether crosscutting concerns are desirable; evaluative weight belongs to choosing and assessing a particular weave. Human practice supplies the programming language, join-point vocabulary, and eligible binding rules, so the utility's origin is institutional and engineered rather than a naturally occurring kind. “Selection,” “integration,” and “tool” travel to other fields as vocabulary, but the software aspect and join-point mechanism does not travel with them. One may recognize the five-role skeleton in a new compiler or service without importing AspectJ's syntax; that recognition is a comparison, not evidence that the named aspect weaver operates outside software. Its character: structurally defined but software-framed, because its repeatable selection-and-integration relation is stable while its sites, concern semantics, and reach depend on a designed programming environment.
Structural Core vs. Domain Accent¶
The skeletal relation is a callable capacity that accepts a base and a separately specified addition, selects eligible sites, integrates the addition, and yields an operative effect. The domain-bound mechanism is aspect-oriented software semantics: pointcuts or equivalent interception rules, advice or introductions, program sites, and supported build or runtime mechanisms. A generic transformation or injection tool may share the relation but lacks this named identity unless its concern-to-site binding is established. Class-loader visibility and language support constrain selection and integration rather than adding another necessary role.
The portable skeleton is a possible future general-tool abstraction, subject to a separate all-instance catalog test. The cited cases establish only a software-specific family; this named entry does not clear the prime bar because its selector, sites, concern representation, and operative effect are defined by programming-language machinery. No cross-domain prime or strict compiler parent follows from resemblance alone.
Instantiates / Related Primes¶
The weaver is closely related to Aspect Weaving, the integration operation it can perform. It is also near a Compiler when the implementation translates source or classes, as ac++ and ajc do; ordinary compilation alone does not entail aspect-site selection. A static weave can be analyzed as program transformation, while PROSE's reported dynamic platform changes running behavior through a different carrier. The current catalog has no verified all-instance tool genus for that complete capacity; the operation, transformation, and compiler neighbors identify possible uses or routes, not a strict parent of every weaver.[5][2][3]
Neighborhood in Abstraction Space¶
Aspect Weaver sits in a sparse region of the domain-specific corpus (100th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Interface segregation principle — 0.73
- Software framework — 0.73
- Service Provider Interface — 0.73
- Interface-Based Programming — 0.73
- Change impact analysis — 0.73
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
Aspect Weaving is the performed integration, and woven code is a possible result. A pointcut checker identifies potential sites without necessarily applying a concern. A generic compiler translates code without necessarily binding a separate aspect to selected sites. A framework proxy may make an advised call possible, but proxy behavior alone is not evidence that its creator follows the exact AspectJ or AspectC++ tool contract. The documented phase, input, selector, and resulting effect are the reliable distinctions.
References¶
[1] Eclipse AspectJ Project. “Load-Time Weaving.” AspectJ Programming Guide, current online edition. https://eclipse.dev/aspectj/doc/latest/devguide/ltw.html. Retained full maintainer-guide capture; Introduction and “Load-time Weaving Requirements” plus configuration sections. Supports AspectJ input/output and compile, post-compile, load-time variants; loader visibility and already-defined-class limits. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l
[2] Olaf Spinczyk, Daniel Lohmann, and Matthias Urban. “Advances in AOP with AspectC++.” Software Methodologies, Tools and Techniques (SoMeT 2005), pp. 33–53. Author-hosted full PDF: https://www.aspectc.org/doc/somet-2005.pdf. Relevant PDF pages 4–6 (pointcuts and advice), 12–13 (Reusable Observer and Win32 Errorhandling), 14–16 (ac++ source-to-source architecture), and 18 (overhead discussion). The PDF carries a stale 2003 template header; the author publication index supplies the 2005 bibliographic identity. Worked examples were inspected as author accounts, not rerun. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k
[3] ETH Zurich PROSE Project. “PROSE.” Archived project account. https://prose.ethz.ch/. Overview and “About the PROSE project” describe extension deployment, affected execution points, retraction, and alternative debugger, JIT, and bytecode mechanisms. This is a primary project retrospective rather than inspected 2002 methods or benchmark tables. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h
[4] Eclipse AspectJ Project. “The AspectJ Language.” AspectJ Programming Guide, current online edition. https://eclipse.dev/aspectj/doc/latest/progguide/language.html. Retained full maintainer-guide capture; join points, pointcuts, advice, inter-type declarations, and static versus dynamic join-point context. registry ↩a ↩b ↩c ↩d ↩e
[5] Eclipse AspectJ Project. “The ajc Command.” AspectJ Development Guide, current online edition. https://eclipse.dev/aspectj/doc/latest/devguide/ajc.html. Retained full maintainer-guide capture; compiler/weaver inputs and options. This citation establishes the combined tool route, not a universal compiler parent. registry ↩a ↩b
[6] Andrei Popovici, Thomas R. Gross, and Gustavo Alonso. “Dynamic Weaving for Aspect-Oriented Programming.” Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). https://doi.org/10.1145/508386.508404. Original-paper title, author, year, and indexed abstract were inspected through the ETH publication listing and metadata; full paper was unavailable here. Cited only for abstract-level research aim, never for mechanics or numerical results. registry ↩a ↩b