27

私は得ています：

NoSuchMethodError: com.foo.SomeService.doSmth()Z

'Z'これは doSmth() メソッドの戻り値の型が boolean であることを正しく理解していますか? true の場合、このメソッドは Collection を返すため、そのようなメソッドは実際には存在しません。しかし一方で、このメソッドを呼び出す場合、その戻り値をどの変数にも代入していません。このメソッドを次のように呼び出します。

service.doSmth();

このエラーが発生する理由はありますか? 必要なすべての JAR ファイルが存在し、このクラスの他のすべてのメソッドが存在するようです。

4

7 に答える 7

25

メソッドはコンパイル中にクラスパスに存在するように見えますが、アプリケーションの実行中には存在しません。

戻り値の型は問題ないと思います。もしそうなら、それはコンパイルされません。メソッド呼び出しがあいまいな場合、コンパイラはエラーをスローします。これは、2 つのメソッドが戻り値の型だけが異なる場合です。

于 2010-09-12T15:27:50.643 に答える
18

通常、このエラーはコンパイラによってキャッチされます。このエラーは、クラスの定義が非互換に変更された場合にのみ、実行時に発生する可能性があります。

つまり、実行時のクラス/jar ファイルは、コンパイル時に使用したものと同じではありません。

于 2010-09-12T15:23:09.737 に答える
17

これはおそらく、コンパイル時のクラスパスと実行時のクラスパスの違いです。

何が起こっているように見えるかは次のとおりです。

  • コードはdoSmth()、ブール値を返すメソッドを定義するクラス パスでコンパイルされます。バイトコードはdoSmth()Zメソッドを参照します。
  • 実行時にdoSmth()Zメソッドが見つかりません。代わりに Collection を返すメソッドが見つかりました。

この問題を解決するには、(コンパイル時の) クラスパスを確認してください。

于 2010-09-12T15:25:09.517 に答える
2

Eclipse で SVN から更新した後、複数のリンクされたプロジェクトでいくつかの実験的な変更をテストしているときに、この問題が発生していることに気付きました。

具体的には、SVN からすべてのプロジェクトを更新し、.classpath ファイルを手動で編集するのではなく元に戻し、物事をシンプルに保ちました。

次に、リンクされたプロジェクトをパスに再度追加しましたが、関連する jar を削除するのを忘れていました。これが私にとって問題が発生した方法でした。

そのため、コンパイラーがプロジェクトファイルを使用している間、ランタイムはjarファイルを使用していたようです。

于 2012-01-27T19:21:25.203 に答える
0

これが発生する可能性があり、見つけるのが難しい別の方法:

外部 jar 内のメソッドのシグネチャが変更され、IDE でエラーが検出されない場合、呼び出し方法と互換性があるため、クラスが再コンパイルされない可能性があります。

ビルドでファイルの変更をチェックしてから再コンパイルする場合、ビルド プロセス中にクラスが再コンパイルされない可能性があります。

したがって、実行すると、その問題が発生する可能性があります。新しい jar がありますが、独自のコードはまだ古いものを想定していますが、文句を言うことはありません。

それを難し​​くするために、そのようなケースを処理できるかどうかは jvm に依存します。したがって、最悪の場合、テスト サーバーでは実行されますが、ライブ マシンでは実行されません。

于 2015-05-08T21:23:37.007 に答える