IDEA 10.5.2 Aspectj compiler - can't determine superclass of missing type org.springframework.transaction.interceptor.TransactionAspectSupport

this is unfortunately an error that occurs from time to time when developing with AspectJ.

Often, in the classpath of any java application, there are some "dead" classes, that is classes that are there inside some jar, but are never used.

These classes often also miss their dependencies. For example, Velocity (to name one, but most libraries do this) ships with classes to bridge many logging facilities, like log4j, java logging etc.. If you want to use one of them, you also need to include its dependency (like log4j.jar), otherwise if you don't use it, you can not add that dependency.

This is not a problem per se when using the library, because those classes will never be loaded. However, when you use AspectJ things change a bit.

Suppose you have a pointcut like :

execution(int MyClass+.getSomething())

While this pointcut seems very specific, it says "a method named getSomething in any subclass of MyClass". That means that to know wether a certain class meets or not the pointcut, AspectJ has to check all superclasses while weaving.

But what happens if AspectJ tries to do that on a "dead class" as the one mentioned above? It will search for superclass and fail, cause the class is not used and it's dependencies are not satisfied.

I usually instruct AspectJ to only warn me in this situation, instead of raising a blocking error, cause 9 times out of 10 this happens on dead code, and can be safely ignored.

Anther way is to spot which pointcut is causing AspectJ to check that class and try to rewrite it so that the scope is stricter. However this is not always possible.

A dirty, but quick, hack could be to write :

execution(... MyClass+ ....) && !this(org.springframework.....)

This is (usually) optimized by AspectJ so that the !this(....) fails before trying to evaluate the complete execution pointcut .. but it ties your pointcut to a specific situation, so is useful only for testing of last second patching a running system while searching for a better solution.

The one to blame, in this case, is not AspectJ, but libraries that include dead classes, which could (and should) be places in separate modules. Many libraries don't do this to avoid "module proliferation" (like, each library should release single modules for each logging system and so on..), which is a good argument, but can be solved easily and better with recent module management systems (like Maven, Ivy etc..) rather than packing single jar files with tons of classes with unmet dependencies, and then stating in documentation that you need that dependency to load that class.

You'll need to add the spring-tx dependency to clear this:

http://mvnrepository.com/artifact/org.springframework/spring-tx

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>

I just solved a similar problem by making a maven clean.

The error message was almost same, but was about my own classes. So I think the answer from Simone Gianni should be correct, there were some incorrect classes which were generated by IDE for some reasons, so just remove them then it should be fine.