From 3488fe5394e024fcae4837a45fb524147212eae9 Mon Sep 17 00:00:00 2001 From: Alexander Kriegisch Date: Tue, 30 Jan 2024 12:58:07 +0700 Subject: [PATCH] Experimentally change image links Signed-off-by: Alexander Kriegisch --- .../ROOT/pages/developer/compiler-weaver.adoc | 10 +++++----- docs/modules/progguide/pages/examples.adoc | 4 ++-- docs/modules/progguide/pages/gettingstarted.adoc | 2 +- docs/modules/release/pages/README-1.2.adoc | 6 +++--- docs/modules/release/pages/README-1.6.1.adoc | 12 ++++++------ docs/modules/release/pages/README-1.6.7.adoc | 4 ++-- 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/modules/ROOT/pages/developer/compiler-weaver.adoc b/docs/modules/ROOT/pages/developer/compiler-weaver.adoc index ba1b28260..f5784a983 100644 --- a/docs/modules/ROOT/pages/developer/compiler-weaver.adoc +++ b/docs/modules/ROOT/pages/developer/compiler-weaver.adoc @@ -21,7 +21,7 @@ for AspectJ-1.2. runtime and must be redistributed with any system built using AspectJ. This module has no external dependencies and produces a tiny ~30KB jar. -image:images/overview.png[image] +image:overview.png[image] The AspectJ compiler accepts both AspectJ bytecode and source code and produces pure Java bytecode as a result. Internally it has two stages. @@ -94,7 +94,7 @@ aspect A { When parsed, this program will produce the following tree. -image:images/top-tree.png[image] +image:top-tree.png[image] ==== PointcutDeclaration processing @@ -105,7 +105,7 @@ Let's look more closely at the pointcut declaration: pointcut entries(Main o): execution(void doit()) && this(o); .... -image:images/pointcut-dec.png[image] +image:pointcut-dec.png[image] The pointcut declaration is implemented as a subtype of a method declaration. The actual pointcut is parsed by the weaver module. This @@ -131,7 +131,7 @@ postParse, the selector is filled in and several additional arguments are added for the special thisJoinPoint forms that could be used in the body. -image:images/advice-dec.png[image] +image:advice-dec.png[image] At this point the statements field which will hold the body of the advice is still null. This field is not filled in until the second stage @@ -142,7 +142,7 @@ prelude to generating the classfile. The main classes in this module are shown in the following diagram: -image:images/ajdt-uml.png[image] +image:ajdt-uml.png[image] === Weaving back-end (weaver) diff --git a/docs/modules/progguide/pages/examples.adoc b/docs/modules/progguide/pages/examples.adoc index caa74a620..392db2606 100644 --- a/docs/modules/progguide/pages/examples.adoc +++ b/docs/modules/progguide/pages/examples.adoc @@ -287,7 +287,7 @@ aspects, though simple, are not totally trivial. The diagram below gives an overview of the aspects and their interaction with the class `Point`. -image:images/aspects.png[image] +image:aspects.png[image] ===== The `CloneablePoint` aspect @@ -1314,7 +1314,7 @@ is used to connect them. Conference calls between more than two customers will involve more than one connection. A customer may be involved in many calls at one time. -image:images/telecom.png[image] +image:telecom.png[image] ===== The `Customer` class diff --git a/docs/modules/progguide/pages/gettingstarted.adoc b/docs/modules/progguide/pages/gettingstarted.adoc index b7de29e59..2806d4cad 100644 --- a/docs/modules/progguide/pages/gettingstarted.adoc +++ b/docs/modules/progguide/pages/gettingstarted.adoc @@ -60,7 +60,7 @@ The features are presented using a simple figure editor system. A is also a `Display`. Most example programs later in this chapter are based on this system as well. -image:images/figureUML.png[ UML for the `FigureEditor` example ] +image:figureUML.png[ UML for the `FigureEditor` example ] The motivation for AspectJ (and likewise for aspect-oriented programming) is the realization that there are issues or concerns that diff --git a/docs/modules/release/pages/README-1.2.adoc b/docs/modules/release/pages/README-1.2.adoc index 5aa96f30e..9aa8503d8 100644 --- a/docs/modules/release/pages/README-1.2.adoc +++ b/docs/modules/release/pages/README-1.2.adoc @@ -31,7 +31,7 @@ Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler... * xref:#WEAVE_TIME[Is faster], with weaving completing in less than half the time it used to take in many cases. -[[WEAVE_CHART]]image:images/AspectJ11v12.JPG[image]. +[[WEAVE_CHART]]image:AspectJ11v12.JPG[image]. * Supports the xref:#LAZY_TJP[-XlazyTjp option] which produces code that runs faster and uses less memory in some common cases. * Has xref:#INCREMENTAL[much better support for incremental @@ -453,11 +453,11 @@ everything in the Spacewar example run: + `ajdoc` sample output for an aspect source file: -image:images/ajdoc1.JPG[image] +image:ajdoc1.JPG[image] `ajdoc` sample output for advised methods: -image:images/ajdoc2.JPG[image] +image:ajdoc2.JPG[image] [[LTW]] ==== A sample script is supplied that supports load-time weaving from the command-line diff --git a/docs/modules/release/pages/README-1.6.1.adoc b/docs/modules/release/pages/README-1.6.1.adoc index 5a9009cc8..a59e3b0bb 100644 --- a/docs/modules/release/pages/README-1.6.1.adoc +++ b/docs/modules/release/pages/README-1.6.1.adoc @@ -43,7 +43,7 @@ sample piece of source code). . 1100 source files, insane aspect (before(): within(*) \{}) (203000 join points) -image:images/perfSourceCompile_161.jpg[image] +image:perfSourceCompile_161.jpg[image] ==== Binary weaving @@ -60,7 +60,7 @@ aspect (121000 join points) . Binary weaving rt.jar (~12000 classes) with an insane aspect (before(): within(*) \{}) (352000 join points) -image:images/perfBinaryWeave_161.jpg[image] +image:perfBinaryWeave_161.jpg[image] ==== Loadtime weaving @@ -73,7 +73,7 @@ aspect . Binary weaving tools.jar (~1900 classes) with an insane aspect (before(): within(*) \{}) -image:images/perfLTW_161.jpg[image] +image:perfLTW_161.jpg[image] The refactoring work has also reduced the amount of unnecessary garbage created on the heap during the weaving process. The next comparison @@ -87,7 +87,7 @@ during a weave of tools.jar with a code style trace aspect . Second, another run of the same thing . Third, this time using the insane aspect -image:images/heapContents_161.jpg[image] +image:heapContents_161.jpg[image] So in terms of memory required, weaving the insane aspect into tools.jar created 1.4G of 'stuff' over the entire weaving process, compared to @@ -113,11 +113,11 @@ discarded. First, AspectJ 1.6.0, in which memory was never correctly recovered and so an OutOfMemory problem would always occur eventually. -image:images/memLtwStress_160.jpg[image] +image:memLtwStress_160.jpg[image] And now AspectJ 1.6.1: -image:images/memLtwStress_161.jpg[image] +image:memLtwStress_161.jpg[image] === Incremental compilation diff --git a/docs/modules/release/pages/README-1.6.7.adoc b/docs/modules/release/pages/README-1.6.7.adoc index ad2769e41..e1abc246f 100644 --- a/docs/modules/release/pages/README-1.6.7.adoc +++ b/docs/modules/release/pages/README-1.6.7.adoc @@ -94,9 +94,9 @@ when load time weaving a small application loading in Tomcat. For each of 10 iterations (x axis), the top comparison is startup time in milliseconds, the lower comparison is memory used in bytes. -image:images/167speed.png[image] +image:167speed.png[image] -image:images/167Memory.png[image] +image:167Memory.png[image] === Annotation binding -- 2.39.5