I'm getting a weird java.lang.AbstractMethodError running a webapp in eclipse with jetty.

Question

I am working on a project in eclipse that when I launch using the jetty plugin gives me a java.lang.AbstractMethodError: au.com.mycopmpany.impl.MyClassDAOImpl.findById(Ljava/lang/Integer;)Ljava/lang/Object;.

This file compiles file in eclipse, and the code is implementing the method that the error talks about. From my reading this error is that "at runtime" the JVM finds a class that doesn't have this method implemented.

But I can assure you that the MyClassDAOImpl most definatly does have the findById method implemented with the correct signature.

This seems like a bug in the eclipse compiler, as I can fix the issue by doing a maven package from a command prompt, and then run the application within eclipse and it works fine.

It seems that the eclipse compiler has some sort of bug in relation to this class.. I did read something online about a bug with Generic's in the eclipse compiler, (which this class does use Generics) but this base class / interface is re-implemented over and over in our code base, and it is this class that always has problems.

Does anyone know a workaround, or better yet, a fix for this problem?

I can replicate this exception everytime, so if an eclipse compiler developer reads this, and this is a known issue, please feel free to contact me for assistance in tracking down the issue.

Update:

The class with the issue is one of many that implement GenericDAO, where the Generic interface is defined as: public interface GenericDAO

The method in question that is failing is: public T findById(Integer integer) throws APIException;

Answer 1

Try rebuilding your code.

I'm guessing that you've got a DAO interface, and the signatures of the interface and the impl differ slightly enough that the compiler doesn't see the interface as fully implemented by the concrete impl class. Maybe Eclipse is out of synch.

If that doesn't work, see if Eclipse lets you navigate from the interface method to the concrete implementation. If it can't, that's a clue reinforcing what the compiler is telling you.

Check your CLASSPATH. Maybe the impl that you think is being loaded by the JVM isn't.

Check the bug list if you think it's a problem with the compiler.

If you don't see a bug in list, assume that you're the problem. Lots of people use it; a bug that serious would have been discovered and fixed long ago.

Clean out the Jetty deployment - the WAR and all temp files. Rebuild and redeploy. Maybe Jetty is holding onto an older version of the .class file, which would explain why it works on the command line and not when you deploy to the web.

Assume that you're the problem first, last, and always.

UPDATE: Is there a way to switch the JDK that Eclipse uses? Can you point to a Sun JDK?

This is another reason why I detest Eclipse. Your story, if true, would make me even happier to be an IntelliJ user.

Question: Are you implementing IBM's generic DAO?

Answer 2

I know that you've already said that you can navigate the code and it all checks out OK, but have you tried navigating while debugging? If you break just before findById is invoked and then step in do you arrive into your Impl class? This might give you some hints about possible classpath mixups...

Answer 3

You say that it runs fine from the command line using the Sun compiler so I assume that both Eclipse and the Sun compiler are outputting their classes into the same directory?

I have had similar problems where there seems to be an issue with keeping the class files in sync when using both Eclipse and the Sun compiler. Eclipse uses its own built in compiler instead of the Sun compiler and this will produce different class files for the same code (e.g. the serial version UID's do not match).

The best solution I have found is to use a seperate bulid folder for Eclipse and the Sun compiler. This way your source if always in sync but the class files cannot conflict with each other.

Answer 4

Look at your classpath.
It is possible the interface name is duplicated along the classpath in a different package; and that eclipse automagically imported the wrong package.

I spent a good deal of time tearing my hair out when it happened /+:

If you already have the solution, could you please post it here too?

Answer 5

Is the @Override annotation of any help? You might be able to obtain more information about the problem if you can turn this into a compile-time error.

Might also be a good idea to fully qualify the relevant class names in the file in question.