mirrors
/
org.aspectj
mirror of https://github.com/eclipse/org.aspectj.git


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114
							<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 1.8.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>
&copy; Copyright 2014 Contributors.
All rights reserved.
</small></div>

<h1>AspectJ 1.8.3 Readme</h1>

<p>The full list of resolved issues in 1.8.3 is available 
<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.3;">here</a></h2>.</p>

<ul>
<li>1.8.3 available 22-Oct-2014
</ul>

<h2>Notable changes</h2>

<h3>Conditional aspect activation with <tt>@RequiredTypes</tt> - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=436653">Issue 436653</a></h3>

<p>AspectJ is sometimes used to create aspect libraries. These libraries contain a number of aspects often covering
a variety of domains. The library might typically be available as a jar and contains a single aop.xml file that
names all the aspects. The library is then consumed by some application. 
However, the application may not need to use all those aspects
but because they are listed in the aop.xml they will be 'active'. Now the pointcuts in those unused aspects
may not match anything in the application and could be considered harmless but the pointcuts and the aspects
themselves may have references to types in other libraries that the application does not have around. This can lead
to unhelpful <tt>"can't find type"</tt> messages and currently requires the user to add unnecessary entries to their
build dependencies just to keep the unused aspects happy.
</p>
<p>With AspectJ 1.8.3 it is now possible to express a constraint on an aspect. The <tt>@RequiredTypes</tt>
annotation specifies one or more fully qualified types that must be discoverable on the classpath in
order for the aspect to activate. Using this there is no need to add those extraneous dependencies to
an applications build classpath.
</p>
<p>Example:</p>
<pre><code>import org.aspectj.lang.annotation.*;

@RequiredTypes("com.foo.Bar")
public aspect Foo {
  before(): execution(@com.foo.Bar * *(..)) {}
}
</code></pre>

<p>
If the above aspect is listed in an aop.xml for loadtime weaving or passed on the aspectpath for
compile time weaving, if the type <tt>'com.foo.Bar'</tt> is not accessible on the classpath then the
aspect will be turned off and the pointcut will have no effect. There will be no attempt made to
match it and so no unhelpful <tt>"can't find type"</tt> messages.
</p>

<h3>cflow and the pre-initialization joinpoint changes due to Java 7 verifier modifications - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=443477">Issue 443477</a></h3>

<p>There has been a change in the Java7 verifier in a recent patch release of Java7 (update 67) that causes
a verify error for usage of a particular AspectJ construct. The problem occurs if you are using
cflow and it hits the preinitialization join point. The pattern of code generated in that case causes
the verifyerror. In this release of AspectJ we have taken the 'quick' approach to solving this, namely
to avoid advising preinitialization with the cflow construct. This problem appears to come up
when the aspect is non-optimal anyway and hitting preinitialization was never really intended by the 
pointcut writer. For example:

<pre><code>execution(* foo(..)) && cflow(within(Bar))</code></pre>

<p>The use of cflow and within there will actually hit *a lot* of joinpoints, many of which the user probably didn't mean to.
It feels like we actually need a warning to indicate the pointcut is probably suboptimal. What the user probably
meant was something more like this:</p>

<pre><code>execution(* foo(..)) && cflow(execution(* Bar.*(..))</code></pre>
<p>or</p>
<pre><code>execution(* foo(..)) && cflow(within(Bar) && execution(* *(..)))</code></pre>

<p>
But even if they did want the less optimal form of cflow there still seems little use in applying it to
pre-initialization - that is your cue to raise an AspectJ bug with a realistic use case inside that proves this
an invalid assumption :)</p>

<h3>around advice and lambdas - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=445395">Issue 445395</a></h3>

<p>For optimal performance, where possible, AspectJ tries to inline around advice when it applies
at a joinpoint. There are few characteristics of a joinpoint match that can prevent this but we
do try to inline where we can (the inlining can be manually turned off via <tt>-XnoInline</tt>).</p>

<p>Inlining of around advice basically means copying the advice instructions into the target class. This causes
a problem when the advice uses lambdas. Lambda usage is currently implemented in java compilers by generating
invokedynamic bytecode instructions that reference bootstrap methods created in the class and a helper method
generated in the class containing the lambda code. When the invokedynamic is encountered at runtime, some magic
happens and the bootstrap method is used to generate a class on the fly that calls the particular lambda method.
All this 'extra stuff' breaks the basic inlining algorithm that simply copies the advice bytecode into the target.
Effectively the inlining process needs to become much more sophisticated and copy the bootstrap methods and
the lambda helper methods, avoiding clashes with existing bootstrap/helpers in the target.</p>

<p>
Prior to AspectJ 1.8.3 when the inlining failed you would get a horrible class cast exception that mentions
constant pool entries (because the bootstrap method hadn't been copied over to the target). Temporarily in
1.8.3 we are turning off inlining of around advice containing lambdas, which will at least avoid the failure,
with the longer term goal of improving the inlining process to do all the necessary extra work.
</p>

<!-- ============================== -->  
</body>
</html>