Save 37% off PRO during our Black Friday Sale! »

Goodbye JSR305, Hello JSpecify!

4ccf6c02807d06f043a71435c48ce86a?s=47 Kengo TODA
November 21, 2021

Goodbye JSR305, Hello JSpecify!

4ccf6c02807d06f043a71435c48ce86a?s=128

Kengo TODA

November 21, 2021
Tweet

Transcript

  1. Goodbye JSR305, Hello JSpecify! Kengo TODA @ JJUG CCC 2021

    Fall
  2. このLTについて JSR305(https://jcp.org/en/jsr/detail?id=305)に代わる静的解析用標準アノテーション の策定を目指す活動(https://jspecify.dev/)について紹介します。 2

  3. スピーカーについて 3 • Kengo TODA ◦ SpotBugs (FindBugs後継) メンテナのひとり ◦

    JSpecifyにはSpotBugs Teamとして参画 ◦ 他にも spotbugs-gradle-plugin, gradle-semantic-release-plugin, などを開発 • 過去のJJUG CCCセッション ◦ Java8〜16におけるバイトコード生成の変化 ◦ SpotBugs3.1.xの現状と内部実装が抱える問題 ◦ SpotBugs(FindBugs)による 大規模ERPのコード品質改善 ◦ etc.
  4. 身近にあるJavaの未解決問題 4 https://stackoverflow.com/a/42695253/814928

  5. Javaの未解決問題 5 • アノテーションの誕生(J2SE 5.0)から17年経った今も、静的解析用ア ノテーションの決定版がない • プロジェクトごとに最適のアノテーションとその使い方を検討しなけれ ばならない •

    標準化されていないので挙動がそれぞれ異なる
  6. 静的解析用アノテーション発展の歴史(~Java SE 8) 6 2004/Sep J2SE 5.0 2006/Aug JSR305 launched

    2006/Jul FindBugs annotations 2007/May Checker framework 2008/Mar JSR305 annotations 2009/Jan Netbeans api-annotations-common 2012/Jan JSR305 annotations v2 2012/May JSR305 was marked as dormant 2009/Jan the last discussion at jsr-305 Google Group
  7. 静的解析用アノテーション発展の歴史(~Java SE 8) 7 2004/Sep J2SE 5.0 2006/Aug JSR305 launched

    2006/Jul FindBugs annotations 2007/May Checker framework 2008/Mar JSR305 annotations 2009/Jan Netbeans api-annotations-common 2012/Jan JSR305 annotations v2 2012/May JSR305 was marked as dormant 2009/Jan the last discussion at jsr-305 Google Group • J2SE 5.0のアノテーションを使えば、静的解析に活用可能な情報を更 に追加できるというアイデア • FindBugsとChecker frameworkが先鞭、JSR305を立ち上げ • 独自アノテーションはまだ多くない
  8. 静的解析用アノテーション発展の歴史(Java SE 8~) 8 2014/Mar Java SE 8 2014/Apr CF

    checker-qual 2014/Jul JSR305 annotations v3 2014/Jul Eclipse JDT annotations 2017/Feb Infer annotations 2017/May Android support library annotations 2017/Sep SpringFramework v5 with annotations (SPR-15540) 2013/Dec Jetbrains Annotations 2017/Sep Java SE 9 2017/Aug KEEP: JSR-305 custom nullability qualifiers
  9. 静的解析用アノテーション発展の歴史(Java SE 8~) 9 2014/Mar Java SE 8 2014/Apr CF

    checker-qual 2014/Jul JSR305 annotations v3 2014/Jul Eclipse JDT annotations 2017/Feb Infer annotations 2017/May Android support library annotations 2017/Sep SpringFramework v5 with annotations (SPR-15540) 2013/Dec Jetbrains Annotations 2017/Sep Java SE 9 2017/Aug KEEP: JSR-305 custom nullability qualifiers • Java SE 8リリース後に独自定義が増加 • JSR305 v3はJavadocの更新のみ • KotlinサポートのためNullnessを明示する必要性が増加
  10. なぜ静的解析用アノテーションが多く作られたのか 1. “標準”APIが機能不足だった a. Genericsや型の使用(TYPE_USE)をサポートしていない 2. “標準”APIが持続可能ではなかった a. JSR305が休止状態とされた b.

    "javax." パッケージの利用が認められていないため、互換を保っての forkができない c. API設計が不明かつ仕様が文書化されていないため、建設的な議論の土台として使いにくい d. "javax.annotation" パッケージが@Generatedなど他の公式モジュールに使われている i. Java moduleは各パッケージがひとつのモジュールからのみ提供されることを前提としている (a.k.a. split packages problem) 3. Kotlin起因によるNullness明示手法への再注目? 10
  11. 標準アノテーションが無いことによる課題 • アノテーションを扱う処理の複雑化 ◦ Kotlin v1.5.31は8種類ものアノテーションに対応 ◦ すべてのツールにすべてのアノテーションを対応させるのは非現実的では? • 実装ごとにアノテーションの解釈が変わる

    ◦ 「ツールAの@NotNullの解釈がツールBと違う」などが発生 ◦ 親クラスやインタフェース、パッケージのアノテーションが競合した際の解釈の揺れ ◦ Java APIの扱いもばらばら(例: System.outはNullableかNonNullか?) 11
  12. そうだ!新しい標準を作ればいいんだ!(?) 12

  13. この未来を回避するためにJSpecifyが目指しているもの • 既存ツールのコミュニティと合意を得ることを意識 ◦ People from the following projects and

    organizations are collaborating on this project: Facebook (Infer), Google (Android, Error Prone, Guava), JetBrains (IntelliJ IDEA, Kotlin), Uber (NullAway), PMD Team (PMD), VMWare (Spring), SonarSource (SonarQube), SpotBugs Team (SpotBugs), Square ◦ Checker frameworkのサポートも視野 • まずNullnessに絞り、関連機能を試験的に実装してもらう ◦ Kotlin 1.5.20: Support for JSpecify nullness annotations ◦ IntelliJ IDEA: 実装中 ◦ SpotBugs: プラグイン実装中 13
  14. JSpecify 0.2.0が提供するもの 14 • Nullness関係の2つのアノテーション ◦ @NullMarked: 修飾されたクラスやパッケージにおいて、型の使用は明示されない限り非 null ◦

    @Nullable: 修飾された型の使用が nullを含むことを明示 • 議論と改善の機会 ◦ github.com/jspecify で様々な議論を実施 ◦ ドキュメントの日本語化は、ある程度議論が落ち着いてからの予定 • リリースノートに記載の注意点 ◦ アノテーションをMaven Centralで公開しているが、1.0までに仕様を変更する可能性が高い ◦ これを利用したライブラリをリリースしないように注意
  15. まとめ:静的解析用標準アノテーションを作りたい • JSR305は保守されず、Kotlinのような新しい技術が求める機能を持たない • いたずらに”新標準”を作ると単に混乱を生むだけ • コミュニティを巻き込んで合意を作り、使われる”最後の標準”を作りたい 15

  16. 参考資料 1. JSpecify公式サイト (jspecify.dev) 2. JVMLS19 overview presentation 3. JSpecify

    v0.2.0 release note 4. Eclipse FoundationによるJSR305を吸収する案 16
  17. Appendix: 独自定義がQualifier Nicknameかどうか 17 Annotation is JSR305 Qualifier Nickname? Checker

    framework N FindBugs/SpotBugs N Netbeans Y Jetbrains N Eclipse JDT N Infer N Android Support Library N Spring Framework Y Lombok N RxJava 3 N