Here’s one solution to one cause, there might be other causes as well. The error means that the class definition existed when compiling but disappeared in the meantime (see Sun Documentation). You see this from the fact that this error message is thrown e.g. when deleting a necessary .class file in the bin output folder of a project. (However, deleting a .class file may also result in java.lang.ClassNotFoundException, for classes that are dynamically loaded by some configurable class loader utility.
In this case, a plugin needed a library (JDOM), which was capsuled in another plugin. Note that these errors are hard to trace with a debugger: the line that generates the exception may need one type of the required library in the other plugin, and that type might be a subtype of the one that’s in the error message, or similar complicated things. With the debugger, you cannot “step into” the loading of statically bound .class files (that’s behind the scenes), and therefore just see this error message appearin out of nothing. You can, however, “step into” the loading of dynamically loaded classes, where some configurable class loader utility is involved.
First, here’s the list of things that did not help:
- It was no problem of a missing .class file, as the required .class file was in place.
- Cleaning and rebuilding the at.ezra.thirdparty.jsword project (equivalent to deleting bin/*) changes nothing regarding these errors. So it’s not just due to a missing or erroneous .class file.
- “PDE-Tools -> Update classpath…” for all or some plugins does not cure the errors.
- It might be necessary to include a plugin dependency to the plugin that contains the library, even if Eclipse doesn’t demand this. Eclipse might not notice that this dependency is necessary if the library is just necessary in dynamically loaded classes, involving some configurable class loader utility. However, this did not solve the issue here.
- It was no problem of lacking dependencies etc. between the two plugins, as the error even arouse when placing the library .jar file directly into the plugin that needed it.
And now, the thing that did the cure:
- Open MANIFEST.MF of the plugin that contains your not-found class definition (here the library plugin). Use the Eclipse manifest editor for this.
- Go to tab “Runtime”, section “Classpath”, click “New” and enter “.” in the edit box. That’s it. In this tab, it’s written that the plugin root dir is automatically (!) the plugin’s class path, but they mean, only if there are no additional entries, in which case one must enter “.” additionally. You need additional entries if you plugin’s library file is located outside of the plugin root dir, e.g. in “lib/”.
The result is a new line “.” (last line in code below!) in the build.properties file, meaning that the plugin’s root dir is now included into the plugin’s classpath. Only then, the .class files in the bin directory can be found, as the bin directory is placed below the plugins root dir. (This whole thing might be an Eclipse bug, actually …).
bin.includes = META-INF/,
Additionally, the following steps might be necessary: add the following lines in the plugin’s build. properties file (they might be missing, but at least the src.. and bin.. lines should be present in all plugins):
jars.compile.order = .
source.. = src/
output.. = bin/
A tip: the general process of removing path-related / class search related errors is probably this: compare build.properties, .classpath and MANIFEST.MF with working species of these files from other plugins.
And if you get a “java.lang.LinkageError: <some class>” error, this might be just a synonym of this error, so check this first.