diff options
| author | Alexander Kriegisch <Alexander@Kriegisch.name> | 2024-01-30 13:44:19 +0700 |
|---|---|---|
| committer | Alexander Kriegisch <Alexander@Kriegisch.name> | 2024-01-30 13:53:50 +0700 |
| commit | 0dee7d2d97ebe16eb46124f5b8b0e23fbf6f3569 (patch) | |
| tree | d247191b46c22f13f2af87a4b21d4701ca8109f7 /docs/modules/release/pages/README-1.6.1.adoc | |
| parent | 146bf2c916113637954352199bb97dc528aacb79 (diff) | |
| download | aspectj-0dee7d2d97ebe16eb46124f5b8b0e23fbf6f3569.tar.gz aspectj-0dee7d2d97ebe16eb46124f5b8b0e23fbf6f3569.zip | |
Headlines per ADOC file should start at level 1, not 2
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Diffstat (limited to 'docs/modules/release/pages/README-1.6.1.adoc')
| -rw-r--r-- | docs/modules/release/pages/README-1.6.1.adoc | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/docs/modules/release/pages/README-1.6.1.adoc b/docs/modules/release/pages/README-1.6.1.adoc index a59e3b0bb..c04fc6eda 100644 --- a/docs/modules/release/pages/README-1.6.1.adoc +++ b/docs/modules/release/pages/README-1.6.1.adoc @@ -1,4 +1,4 @@ -== AspectJ 1.6.1 += AspectJ 1.6.1 _© Copyright 2008 Contributors. All rights reserved._ @@ -21,14 +21,14 @@ implemented] ''''' -=== Refactored (https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396[bug 231396]) +== Refactored (https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396[bug 231396]) The bugzilla entry goes into more specifics on what has changed, the end result is that aspectjweaver.jar has had around 275 classes removed (about 25%) and has slimmed down by 350k (about 20%). In terms of performance for different scenarios: -==== Straight compilation +=== Straight compilation The refactoring effort has been focused on the weaver component, hence there is limited impact on the performance of source compilation but @@ -45,7 +45,7 @@ join points) image:perfSourceCompile_161.jpg[image] -==== Binary weaving +=== Binary weaving Moving on from source compilation to pure binary weaving, the improvements are more obvious. Here we are using the complete JVM @@ -62,7 +62,7 @@ aspect (121000 join points) image:perfBinaryWeave_161.jpg[image] -==== Loadtime weaving +=== Loadtime weaving The loadtime weaving improvements are similar to those seen for binary weaving (naturally). Here we are using the JDK tools jar 'tools.jar' as @@ -93,7 +93,7 @@ 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 1.75G with 1.6.0. -==== Loadtime weaving stress +=== Loadtime weaving stress As well as addressing the memory usage of a single load time weaver, we have also looked at the use of load time weaving in a larger scale @@ -119,7 +119,7 @@ And now AspectJ 1.6.1: image:memLtwStress_161.jpg[image] -=== Incremental compilation +== Incremental compilation Following on from the work done to improve compilation under Eclipse in AspectJ 1.6.0 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[Bug @@ -138,9 +138,9 @@ with known errors, and this means AspectJ will more frequently do incremental builds rather than falling back to full builds because there was a compilation error. -=== Language changes +== Language changes -==== Optmized syntax for annotation value binding (https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943[Bug234943]) +=== Optmized syntax for annotation value binding (https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943[Bug234943]) If only binding an annotation at a method-execution join point in order to access an *enum value* within it, there is a more optimal syntax that |