Eclipse rcp classloader hell: moved class still visible at compiletime but not at runtime anymore

Question

I've a strange and new issue with an eclipse 3.5 rcp application: Everything worked fine, then I changed the running system and moved a single class from one plugin to a dependent plugin. No big issue, but all of a sudden the application complains with a class not found exception (or NoClassDefFoundError - don't know exactly but will look it up and edit the post...)

I double, triple, ... checked all that I know, and made sure, that the manifest contains the dependancy with the correct version number and that the package is correctly exported in the other plugin. Eclipse jdk doesn't complain (no compiler errors/warnings) but when I debug just to the point where the class is instantiated and use 'CTRL+SHIFT+I' to inspect the 'new MyClass()' statement, the inspectors tooltip sais, that it can't resolve that class.

Any help, hint and encouraging comment is highly appreciated!

Answer 1

Solved the issue just by chance (and don't have the faintest idea whether this was a bug or a feature...):

The plugin project, where I moved the class into, had a maven-like folder structure with src/main/java and src/test/java, both folders defined as source folders.

Just because I wanted to try almost everything, I changed this structure back to the typical eclipse structure with just src as the single source folder.

And, after another 'project clean', it's running again. Strange...?

Edit

thanks for the hint, the folder structure was just a typo in this post.

After a lot more struggle - I'm quite positive that this was an eclipse issue. After 'solving' as above, the very next day the application failed to load other classes from the same plugin and I think, after a restart of the Galileo workbench, the problems are gone.

Answer 2

I also encountered a NoClassDefFoundError in an Eclipse 3.5 Galileo RCP app where I had a src/java folder in one plugin and needed to export a package for use by another plugin.

The solution for me turned out to be including the bin folder as part of the runtime class path. Normally it's only been necessary to include the . folder.