File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes AbstractMethodError Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "AbstractMethodError" Watch "AbstractMethodError" New topic
Author

AbstractMethodError

Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
Hi Guys,

I'm working on a project that involves plugins. I developed both the main application and a plugin for it. I have a problem with method in particular that I use in my plugin class. My main app loads the plugin and when I launch my main app I run the following test during initialization:



I get the following stack trace:

plugin: com.personalnetsearch.plugin.jl.PNS_JobLogPlugin isVisible: false

Exception in thread "main" java.lang.AbstractMethodError
at com.personalnetsearch.parser.MainGUI.jbInit(MainGUI.java:546)
at com.personalnetsearch.parser.MainGUI.<init>(MainGUI.java:183)
at com.personalnetsearch.parser.MainGUI.main(MainGUI.java:172)

Notice the println statement still prints out followed by the error message.

If I remove the call to plugin.isVisible(), I don't get AbstractMethodError.

I don't quite understand why calling plugin.isVisible() causes the error and calling any of the other methods (plugin.haveGUI() and plugin.getName()) doesn't.
The default is for the plugin to return false on the call to isVisible() since, during initialization, it hasn't been diplayed yet. In fact, as an aside, each plugin has a method display() which either creates a new instance of a JFrame or calls setVisible(true) on the JFrame if it is merely invisible. This shouldn't have any bearing on the problem that I can see.


I thought perhaps there was a method name conflict, so I renamed the method isGUIVisible(). Still the same problem.

Please advise,

Alan
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3476

AbstractMethodError
Thrown when an application tries to call an abstract method. Normally, this error is caught by the compiler; this error can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Well, if you read the docs for that error, you'll see this:

Thrown when an application tries to call an abstract method. Normally, this error is caught by the compiler; this error can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.


So maybe you changed something and didn't recompile everything?
Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
I did read the docs, and the only thing I changed is the interface the plugin implements:



I added the method isVisible() and thinking there was a naming conflict after I got the error message I changed it to isGUIVisible().



So, now my plugin class looks like:



I recompiled at both ends but still I'm getting that #%$^&* error message at run time. I don't know what I need to do to fix it. Please advise.

Alan
Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
Hi Guys,

I was lying in bed mulling this over and over in my mind. ...It's 1:30am in the morning here... Then it dawned on me. Remember the readout of the printlin statements in the while loop? Remember this line?

plugin: com.personalnetsearch.plugin.jl.PNS_JobLogPlugin isVisible: false

That was the clue! The fact that this printed out fine indicated that the plugin I was working on did compile fine and adhered to the change I made in PNS_Plugin interface. I discovered the problem. There were other, older plugins in the "plugins" directory the main app was accessing which weren't recompiled after I had made the change. So it wasn't complaining about the plugin I was currently working on. It was complaining about the other plugins I hadn't updated and recompiled yet.

I can go back to bed and finally sleep now. I'll definitely remember this debacle.

Thanks, hope this helps someone else at some point.

Alan
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37958
    
  22
I don’t like all those else-ifs about Locale. You would be better using a Map to store such information.
Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
Hmmm...you've got a point. I'll work on that and see if I can improve on it.

Alan
Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
Hi Campbell,

I've been working on your suggestion regarding putting the supported Locales into a HashMap. I did that like so:



While doing this makes it more succinct in my objective, I can't say it really reduces the amount of code any. I still wind up with an if/else structure. Did you have something better in mind?

Alan
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37958
    
  22
You mean . . .
You would have to check that those Locales have overridden equals() and hashCode() methods so the Map will work correctly.
Internationalisation is a big subject. There is a whole section in the Java™ Tutorials about it.
Alan Shiers
Ranch Hand

Joined: Sep 24, 2003
Posts: 237
How's this. Just a little better:



It compiled and ran perfectly.

Alan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: AbstractMethodError
 
Similar Threads
AbstractMethodError
AbstractMethodError
AbstractMethodError
AbstractMethodError
AbstractMethodError while doing prepareCall()