Is AspectJ required on the classpath when weaving at compile-time?

Question

I asked this question a few days ago, and managed to get it working using compile-time weaving.

However, when the application runs and it invokes the toString() method which I mixed into my DTO via AOP, I get the exception below.

I didn't expect AspectJ to be required in the runtime classpath. After all, I've used compile-time weaving, so the bytecode should already be in its final state, right? Why is AspectJ expected to be present at runtime?

java.lang.ClassNotFoundException: org.aspectj.lang.NoAspectBoundException
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)[osgi-3.6.2.R36x_v20110210.jar:]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)[osgi-3.6.2.R36x_v20110210.jar:]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)[osgi-3.6.2.R36x_v20110210.jar:]
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)[osgi-3.6.2.R36x_v20110210.jar:]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_35]
    ... 51 more

Is there a way to instruct AspectJ to drop all references to itself in the resulting bytecode?

NB: I'm running in an OSGi environment - but that's definitely irrelevant.

Answer 1

Whether you use compile-time, post-compile-time or load-time weaving, the woven bytecode will have a dependency on a small number of types - shipping them in a jar is seen as easier than generating them into every compiled app. These types are encapsulated in the small jar 'aspectjrt.jar'. You won't need the weaver jar or the compiler jar on the classpath, just the small runtime jar. It contains a few different things:

• definitions of the runtime visible annotations that might have been used to write the aspect (@Before, @Aspect)
• exception types for when things go wrong (NoAspectBoundException) or to implement language features (SoftException)
• utility code to implement some language features, for example cflow threadlocal stack management.
• all the support classes for thisJoinPoint. When you access something like getSignature() on thisJoinPoint you might get back a MemberSignature.

If would be possible to avoid a lot of these if you aren't using those language features, but NoAspectBoundException would likely still be an issue - even the simplest aspect will depend on that. Right now there is no way to compile that will avoid the jar dependency entirely.

It would be possible to modify AspectJ to do extra code generation to avoid the dependency entirely, but that isn't a common request and so no work has been done on it.

(There are builds of aspectjrt.jar that include the right OSGi manifest info, for use in that environment - the jar included in the standard distro doesn't get that manifest correct right now)

Answer 2

我相信无论编织何时发生，您仍然需要AspectJ运行时库。