AspectJLint

This page lists AspectJ Lint messages, and explanations on how to solve them or what could be affected by them.

Lint messages are produced by the AspectJ compiler/weaver to warn the user about a possible problem.

invalidAbsoluteTypeName (warning)

The weaver is not able to resolve an absolute type name. For example, if you write :

 pointcut mymethod() : execution(String com.nonexisting.missingClass.get*());

The weaver will warn that com.nonexisting.missingClass is an invalid absolute type name.

By default, the weaver will issue only a warning and not a compile error. This is because it is legal to write a pointcut on a class not present at present compile time. It will be applied to that class if it is present at a later weaving stage, like during LTW or when the aspect is on the aspectpath of another build containing that type.

Solutions :

• Check your classpath, inpath and aspectpath to see if you are missing the dependency that contains the missing type.
• If you are developing an aspect library, you could decide to ignore this Lint. The missing type could be present when the aspect library is weaved on the real target project.

invalidWildcardTypeName (ignore)

TODO

unresolvableMember (warning)

TODO

typeNotExposedToWeaver (warning)

The weaver has correctly identified a type that should be weaved, but in current configuration that type is not in the same project as the aspect nor added to a library on the inpath, so it was not possible to weave it.

This is a warning because it is perfectly legal to write a pointcut against a type not currently exposed to the weaver. The weaver will be able to match that pointcut at a later weaving stage, like during LTW or when the aspect is on the aspectpath of another build containing that type.

Solutions :

• If you expect the statement to weave into a library, check that the library is on your inpath.
• If you are developing an aspect library, you can usually ignore this Lint, it will be resolved when the aspect library is finally weaved.

shadowNotInStructure (ignore)

TODO

unmatchedSuperTypeInCall (warning)

TODO

canNotImplementLazyTjp (ignore)

Normally the weaver will try to not instantiate the "thisJoinPoint" variable until it is necessary. However sometimes it fails to implement such a check.

This happens often for around advices. Runtime performances could be affected.

TODO : which other common situations trigger this Lint?

Solutions :

• Check if you can use thisJoinPointStaticPart instead of thisJoinPoint.
• Ignore this Lint unless you have a real runtime performance problem.
• Try if you can rewrite "around" pointcuts as before/after pairs.
• Reduce the scope of advice, this will not remove the Lint but will reduce the performance impact.

multipleAdviceStoppingLazyTjp (ignore)

TODO

noGuardForLazyTjp (ignore)

TODO

uncheckedAdviceConversion (warning)

TODO

needsSerialVersionUIDField (ignore)

TODO

brokeSerialVersionCompatibility (ignore)

TODO

noInterfaceCtorJoinpoint (warning)

TODO

noJoinpointsForBridgeMethods (warning)

TODO

cantMatchArrayTypeOnVarargs (ignore)

TODO

enumAsTargetForDecpIgnored (warning)

Currently Enum types cannot be the target of an ITD declare parents, for example to have them implement an interface. It can happen however, if you are adding an interface to all types in a package for example, that also an enumeration is between those types, so it is signaled as a warning.

Theorically Enums could support ITDs, there have been a couple of mails asking for this feature on the mailing list.

Solutions :

• Check the scope of your "declare parents" statements.

annotationAsTargetForDecpIgnored (warning)

Annotations, defined by "The Java Language Specification", cannot extend or implement any other type. It can happen however, if you are adding an interface to all types in a package for example, that also an annotation is between those types, so it is signaled as a warning.

Solutions :

• Check the scope of your "declare parents" statements.

adviceDidNotMatch (warning)

The pointcut for that advice did not match any join point between those exposed to the weaver. This could mean that the pointcut is not correct, and it's not matching anything it should match.

It could also mean that in the current project and inpath there is no occurrence of the join point designated, which could not be a problem if you are writing an aspect library designed to be later weaved on a different project. This is why it's reposted as a warning.

Solutions :

• If you are developing an aspect library, you can usually safely ignore this Lint.
• If you expect the advice to match, there is an error in your pointcut.

invalidTargetForAnnotation (warning)

When using @declare to declare a new annotation, the given annotation is not compatible with the target of @declare. For example, you can write :

 declare @type : MyClass : @java.lang.annotation.Documented;

And try to apply the @Documented annotation to the class "MyClass". But since @Documented can be applied only to other annotations, and not to classes, this will raise the warning.

It can happen however, if you are adding an annotation to all types in a package for example, that the annotation is not applicable to those types, so it is signaled as a warning.

Solutions :

• Check the scope of your @declare statements.

elementAlreadyAnnotated (warning)

As specified by The Java Language Specification, an annotation cannot be repeated twice on the same target. For example, you cannot specify @Deprecated twice on the same method, even when such a double annotation would not cause harm.

When using @declare to add new annotations on existing members, it can happen that one of those members already has the specified annotation. AspectJ will not add the annotation on those member.

Solutions :

• Check the scope of your @declare statements.

runtimeExceptionNotSoftened (warning)

TODO

uncheckedArgument (warning)

TODO

noExplicitConstructorCall (warning)

TODO

aspectExcludedByConfiguration (ignore)

TODO

unmatchedTargetKind (warning)

TODO

cantFindType (error)

Generically, this error means that AspectJ cannot find a type needed for correct weaving. This Lint is an umbrella for a number of situations. The missing type could be an annotation, an exception, a class etc..

When you see this error, it usually means that your classpath is not consistent with the compile time classpath. For example, if you compile a few classes using library.jar, then package those classes in mylibs.jar, then include mylibs.jar on the classpath of a project without including also library.jar . Classes in mylibs.jar will contain references to classes in library.jar, but AspectJ will not be able to find them.

This situation is similar to ClassNotFoundException runtime error, but with a subtle difference. The JVM resolves types only when they are needed for execution, while AspectJ will need to resolve some of them also during weaving.

A common situation where this difference is crucial is with libraries and logging library implementations. Quite often libraries like Hibernate or Velocity, supports many loggers, like Log4J, commons-logging, java.util.log etc..

They try to detect at runtime which logger to use. For example, they could contain code like the following :

public class Log4JFacade implement LogFacade {

 public void debug(String message) {
   log4JLogger.debug(message);
 }
 // ...

}

public class LoggerFactory {

 public static LogFacade getLogger() {
   try {
     Class.forName("org.apache.log4j.Logger");
     return new Log4JFacade();
   } catch (ClassNotFoundException e) {
   }
   // try other loggers
 }

}

This makes it possible to use such a library without providing also log4j.jar, or any other logger implementation.

This is correct Java code, cause the JVM will load the Log4JFacade class only after the runtime check for the presence of the org.apache.log4j.Logger class.

However, if you are weaving such a library, AspectJ will try to analyze Log4JFacade to see if it matches an advice of yours, and if log4j is not present it will fail with this error.

Solutions :

• Try to scope your advices properly, AspectJ is probably trying to match classes that it should not.
• Include all needed dependencies on the compile classpath, like log4j.jar in our example.

cantFindTypeAffectingJPMatch (warning)

TODO

unorderedAdviceAtShadow (ignore)

TODO

swallowedExceptionInCatchBlock (ignore)

TODO

calculatingSerialVersionUID (ignore)

TODO

advisingSynchronizedMethods (warning)

Ths warning is signaled when an advice is applied on a synchronized method, and -Xjoinpoints:synchronization.

See the related enhancement request.

mustWeaveXmlDefinedAspects (warning)

TODO

missingAspectForReweaving (error)

This error happens when AspectJ is reweaving a class previously weaved with a now missing aspect.

Suppose you have an aspect library, for example tracer.jar, containing a tracing aspect. You compile a project of yours having tracer.jar on the aspectpath, so classes from your project contains calls to the tracing aspect.

Then you place yourproject.jar on the inpath and to weave also another aspect library in it, but does not include tracer.jar on the aspectpath again. In this situation, AspectJ will not find the tracer aspect when analyzing yourproject.jar classes, and throw this error.

Solutions :

• Check your aspectpath to make sure it include all aspect libraries.
• If you removed an aspect from an aspect library, you may need to rebuild the projects using that aspect library.

cannotAdviseJoinpointInInterfaceWithAroundAdvice (warning)

TODO