私たちの会社には、ソース コード (実際にはほとんどすべてのソース コード) と共に購入した巨大なアプリケーションがあり、それを私たちのニーズや修正などに適応させる作業を行ってきました。プロジェクトをコンパイルするには、元の会社のプリコンパイル済み jar を用意し、必要なクラスのみを編集または追加して、元のソース コードを含む zip ファイルから取得した Override フォルダーに追加することをお勧めします。したがって、コンパイルするときは、編集したクラスのみをコンパイルし、クラスパスで元の jar を使用してから、新しいクラスまたは編集したクラスを元の jar と結合して新しい Jar を作成します。
問題は、人々がメソッド コントラクトを変更したり、インターフェイスを編集したり、抽象クラスに抽象メソッドを追加したりしているようです。コンパイルするとき、完全なソース コードを再コンパイルするのではなく、私たちのものだけを再コンパイルするので、コンパイラはオーバーライドされたソース コードのコントラクトの一貫性のみをチェックします。古いクラスがもはや存在しないメソッドを呼び出そうとしている、または実際にはインターフェイスの部分的なバージョンにすぎないものを実装するクラスのメソッドを呼び出すクラスがあるため、問題が発生しているように見えることに気付き始めました。
一部のクラスと Java ファイルはビルド時に自動生成されるため、実際には壊れていないものを誤って修正する可能性があるため、元のソース コードをオーバーライドされたソース コードと単純に結合することはできません。（私は試しました、それが私が知っている理由です）
さまざまなコンパイル済み jar のクラス間の契約の一貫性を自動的に検証する方法はありますか? これらの不一致を修正した後、両方のソース ディレクトリをマージして、将来この問題を回避できます。