- インクリメンタルな実行ができない問題。クラスに変更があった場合、そのクラス自身に加えて依存するすべてのクラスを再解析すべきです。Findbugs単体ではこれができませんが、この論文で紹介されている方法なら可能です。複雑なプロジェクトでのCIサイクル高速化に寄与すると期待されます。
- マルチコアを活かせない問題。Findbugsはそれ自身やプラグインが並列動作を想定していません。この実装変更にはかなりの年月が必要と思われます。
- メモリを効率的に使えない問題。Findbugsの消費メモリは大きく、512mから1gを与えなければ動かないことがあります。RDBを使うこの方法なら比較的効率よくメモリを使えると期待され、メモリ不足で落ちるということも減るのではないでしょうか。
- 各detectorに設定を渡せない問題。Findbugsは設定をdetectorに渡すための公式な方法が用意されていません。この論文で紹介されている方法はそもそもプロジェクトごとにルールを作成することを意識しており、より柔軟な形でルールを策定できると期待できます。
他にもfilterを超える柔軟かつ効果的なインタフェースとか、プラグインの書きやすさとかを実現できると良いと思います。
