这是迄今为止我找到的最好的解决办法。

假设我们有一个名为org的包。Mypackage包含的类:

HelloWorld(主类) SupportClass UtilClass

定义这个包的文件物理存储在目录D:\myprogram (Windows)或/home/user/myprogram (Linux)下。

文件结构如下所示:

当调用Java时，我们指定要运行的应用程序的名称:org.mypackage.HelloWorld。但是，我们还必须告诉Java在哪里查找定义包的文件和目录。所以要启动程序，我们必须使用下面的命令:

当我将另一个模块的Maven依赖添加到我的项目中时，我得到了这个错误，这个问题最终通过添加-Xss2m到我的程序的JVM选项来解决(自JDK5.0以来默认是1m字节)。人们认为程序没有足够的堆栈来加载类。

我发现，当使用运行时发现的不兼容的类版本编译代码时，有时会得到NoClassDefFound错误。我记得的具体实例是apache axis库。在我的运行时类路径上实际上有2个版本，它正在挑选过时和不兼容的版本，而不是正确的版本，导致NoClassDefFound错误。这是在一个命令行应用程序中，我正在使用类似的命令。

set classpath=%classpath%;axis.jar

我能够让它拿起正确的版本使用:

set classpath=axis.jar;%classpath%;

当我没有在项目的Java Build Path中的“Order and export”选项卡上导出一个类时，我得到了NoClassDefFound错误。确保在添加到项目构建路径的任何依赖项的“Order and Export”选项卡中添加一个复选标记。请参见Eclipse警告:XXXXXXXXXXX.jar将不会被导出或发布。可能会导致运行时ClassNotFoundExceptions。

下面的技巧帮助了我很多次:

System.out.println(TheNoDefFoundClass.class.getProtectionDomain().getCodeSource().getLocation());

其中nodeffoundclass是可能会“丢失”的类，这是由于您的程序使用相同库的旧版本的首选项。当客户端软件被部署到一个占主导地位的容器中，并配备了自己的类加载器和大量最流行的库的古老版本时，这种情况最常发生。

我从SRC库中删除了两个文件后得到了这个消息，当我把它们带回来时，我一直看到这个错误消息。

我的解决方案是:重新启动Eclipse。从那以后我就再没见过这条消息了:-)