Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Goodbye JSR305, Hello JSpecify!

Kengo TODA
November 21, 2021

Goodbye JSR305, Hello JSpecify!

Kengo TODA

November 21, 2021
Tweet

More Decks by Kengo TODA

Other Decks in Technology

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