blob: 253d5739fd9374fc0ccc761807f1efa37f6f11d8 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 1.6.3 Readme</title>
<style type="text/css">
<!--
P { margin-left: 20px; }
PRE { margin-left: 20px; }
LI { margin-left: 20px; }
H4 { margin-left: 20px; }
H3 { margin-left: 10px; }
-->
</style>
</head>
<body>
<div align="right"><small>
© Copyright 2008 Contributors.
All rights reserved.
</small></div>
<h1>AspectJ 1.6.3 Readme</h1>
<ul>
<li><a href="#split">Split matching/weaving</a></li>
<li><a href="#bugsfixed">Bugs fixed</a></li>
<li><a href="#notable">Notable bug fixes</a></li>
<li><a href="#whatsnext">What's next?</a></li>
</ul>
<hr>
<a name="split"/>
<H4>Split matching/weaving</h4>
<p>The main goal of AspectJ 1.6.3 was to make the line between matching and weaving more explicit and
introduce the notion of a matcher artifact. This matcher would enable reuse of the semantics of
AspectJ pointcut matching without including the unnecessary code that is the weaver. Why? In some
environments, for example Spring AOP, the weaving may be done in an entirely different way and the
default weaver included in aspectjweaver.jar is just unnecessary code. Some users also find they have trouble getting
approval for using the 'aspectjweaver.jar' in their projects because it includes a bytecode
modification library, even when they are not using that code.
<p>The result of this work is documented in <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125">bug 246125</a>
and there is now a new jar file in the distribution called org.aspectj.matcher.jar that includes
a first pass at the matching code. It is not quite as slimmed down as it could be but is a first
pass that includes no bytecode modification toolkit.
<p>To use this matcher standalone it simply requires an abstraction of some type system to be plugged in.
The matcher code can then be used to parse standard pointcuts and answer questions about whether they match against
that type system. There is no documentation on how to do this yet, as we don't think many users will
be contributing new type systems, but internally we are working on an Eclipse JDT type system abstraction that will
enable us to show matches in AJDT without actually compiling code (currently the two type system abstractions
we ship are bytecode based and reflection based - both of which require compilation).
<hr>
<a name="bugsfixed"/>
<h4>Bugs fixed</h4>
<p>The complete list of issues resolved for AspectJ 1.6.3 (more than 50) can be found with
this bugzilla query:
<ul>
<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.3&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
</ul>
<p>During 2008, there have been four AspectJ releases, fixing almost 200 issues.
<hr>
<a name="notable"/>
<h4>Notable bug fixes</h4>
<ul>
<li>More improvements to the way AspectJ/AJDT communicate (251277, 249216, 258325)
<li>More ajdoc improvements (256514)
<li>Better support for non standard annotation style parameter ordering (164573, 219419)
<li>Fixed long standing issue with extending Spring SecurityInterceptor (252722)
<li>Ensure parameter annotations made on an ITD reach the target affected type (256669)
</ul>
<hr>
<a name="whatsnext"/>
<h4>What's next?</h4>
<p>The JDT World should be completed in the 1.6.4 timeframe and that will surface as benefits in AJDT, possibly leading to better
LTW tooling. Some improved syntax for intertype declarations is a possible candidate feature (see discussion in
<a href="http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10208.html">this mailing list thread</a>).
A possible introduction of a code style syntax for the mixin style that is @DeclareParents (and a renaming of
@DeclareParents to perhaps DeclareMixin or DeclareDelegate).
<hr>
<!-- ============================== -->
</body>
</html>
|
