Community
Participate
Working Groups
Some products are now shipping aspectjrt.jar from the 1.2.1 compiler. We would like the users of these products to benefit from all the latest and greatest enhancements in the tools and compiler when developing their code - however, they will need to deploy this code on a runtime containing the 1.2.1 aspectjrt. We have made some enhancements in the 1.5.0 runtime that affect compatibility - one that springs to mind is changing the signature of the code that builds join point objects to save memory at runtime. We need to enable users to specify they want to deploy on a back level aspectj - something like a "-ajruntimetarget 1.2.1" option only with a better name - this would generate code that ran against the 1.2.1 aspectjrt.jar. At the same time I think we should perhaps (if they aren't there already) reinstate the old way of building join point objects so that code targetting a 1.2.1 runtime will run happily if it finds a 1.5.0 runtime around.
the old way of building join point objects is still present in the runtime library, so there should be no issues on that count. This would be a good enhancement, but one that I'm happy to defer until 1.5.1.
I think it is important for AspectJ to offer binary backward compatibility in the same way that Java does. If we encourage users to move the latest AJDT and not support older verions of AspectJ in Eclipse we should at least allow them to target older platforms when building their code. AspectJ 1.2.1 is currently the only final verion of AspectJ available. Asking users to upgrade aspectjrt "overnight" and recompile/weave all dependent applications seems a little unreasonable considering that in a shared environment such as an application server these applications may not be owned by a single person. Would a "-ajsource 1.2.1" be more appropriate than a target flag? Certain language features may now or in the future have a dependence on the runtime too.
The new methods added for the optimization that is causing problems are in: org.aspectj.runtime.reflect.Factory Every method makeXXXSig() now has an extra variant, so: makeMethodSig(int modifiers, String name, Class declaringType, Class[] parameterTypes, String[] parameterNames, Class[] exceptionTypes, Class returnType) makeMethodSig(String stringRep) were joined by makeMethodSig(String modifiers, String methodName, String declaringType, String paramTypes, String paramNames, String exceptionTypes, String returnType) similarly for: makeConstructorSig, makeAdviceSig, makeFieldSig, makeInitializerSig, makeCatchClauseSig --- The calls to these methods are created in the LazyClassGen.initializeTjp() method. --- the new options is -Xajruntimetarget and can be set to 1.2 or 1.5 (See org.aspectj.weaver.Constants) -Xajruntimetarget:1.2 -Xajruntimetarget:1.5 uses same options mechanism as -Xreweavable did. It is '-X' because we aren't settled on it yet. Is it an option that also polices source features? (so, does it say you can't use pertypewithin() ?) Being -X it can be supplied easily through AJDT or through ANT --- Heres an example with aspectjrt.jar from a 1.2 AspectJ on the classpath: ---8<--- Simple.java public class Simple { public static void main(String []argv) { new Simple().a(); } public void a() {} } aspect X { before():execution(* a(..)) { System.err.println(thisJoinPoint); System.err.println(thisJoinPointStaticPart); System.err.println(thisEnclosingJoinPointStaticPart); } before():execution(Simple.new(..)) { System.err.println(thisJoinPoint); System.err.println(thisEnclosingJoinPointStaticPart); System.err.println(thisJoinPointStaticPart); } } ---8<--- C:\aspectj1.5.0-dev>ajc -Xajruntimetarget:1.5 Simple.java C:\aspectj1.5.0-dev>java Simple Exception in thread "main" java.lang.NoSuchMethodError: org.aspectj.runtime.refl ect.Factory.makeConstructorSig(Ljava/lang/String;Ljava/lang/String;Ljava/lang/St ring;Ljava/lang/String;Ljava/lang/String;)Lorg/aspectj/lang/reflect/ConstructorS ignature; at Simple.<clinit>(Simple.java:1) C:\aspectj1.5.0-dev>ajc -Xajruntimetarget:1.2 Simple.java C:\aspectj1.5.0-dev>java Simple execution(Simple()) execution(Simple()) execution(Simple()) execution(void Simple.a()) execution(void Simple.a()) execution(void Simple.a()) C:\aspectj1.5.0-dev> beautiful ;)
Code is checked in - and one less than ideal testcase (yes, yes - needs a 1000 more) I hope that optimization is the only thing causing us problems with deploying on 1.2 - since it's the only place where I've used the new option to configure the resulting woven code.
I missed one case to do with enclosing static join point static parts.... I've resolved it - tested it - I will tidy it up and check it in tomorrow. An AJDT build will then follow from that.
the further fixes (and more tests) are in - we'll start creating the new AJDT imminently..
The -X option isn't sufficient. Too many complex tools based upon eclipse are merely asking a project for its builder and calling 'build' - this doesn't allow for options to be passed through correctly. So, you can set -Xtargetaspectjruntime:12 in your project properties but it won't have any effect. The right solution for now seems to be to target a 1.2 runtime unless the compiler is running in 1.5 mode, since 1.5 introduces this new code. If running in 1.5 mode, it is still possible to use the -X option to target 1.2 if you need to (if you can get the option through...) This does mean users compiling with <1.5 will not get the benefit of the optimization...
changes checked in as per last comment.
done all intending to do.
