Goodbye JSR305, Hello JSpecify!

JJUG CCC 2021 Fallにて発表したLTです。JSR305に代わる静的解析用標準アノテーションの策定を目指す活動について紹介しています。

https://fortee.jp/jjug-ccc-2021-fall/proposal/12087996-9d3a-46f2-81f1-84869b56f2b5

Transcript

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

   View Slide

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

   View Slide

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.
   

   View Slide

4. 身近にあるJavaの未解決問題
   4
   https://stackoverflow.com/a/42695253/814928
   

   View Slide

5. Javaの未解決問題
   5
   ● アノテーションの誕生（J2SE 5.0）から17年経った今も、静的解析用ア
   ノテーションの決定版がない
   ● プロジェクトごとに最適のアノテーションとその使い方を検討しなけれ
   ばならない
   ● 標準化されていないので挙動がそれぞれ異なる
   

   View Slide

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
   

   View Slide

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を立ち上げ
   ● 独自アノテーションはまだ多くない
   

   View Slide

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
   

   View Slide

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を明示する必要性が増加
   

   View Slide

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
    

    View Slide

11. 標準アノテーションが無いことによる課題
    ● アノテーションを扱う処理の複雑化
    ○ Kotlin v1.5.31は8種類ものアノテーションに対応
    ○ すべてのツールにすべてのアノテーションを対応させるのは非現実的では？
    ● 実装ごとにアノテーションの解釈が変わる
    ○ 「ツールAの＠NotNullの解釈がツールBと違う」などが発生
    ○ 親クラスやインタフェース、パッケージのアノテーションが競合した際の解釈の揺れ
    ○ Java APIの扱いもばらばら（例： System.outはNullableかNonNullか？）
    11
    

    View Slide

12. そうだ！新しい標準を作ればいいんだ！（？）
    12
    

    View Slide

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
    

    View Slide

14. JSpecify 0.2.0が提供するもの
    14
    ● Nullness関係の2つのアノテーション
    ○ @NullMarked: 修飾されたクラスやパッケージにおいて、型の使用は明示されない限り非 null
    ○ @Nullable: 修飾された型の使用が nullを含むことを明示
    ● 議論と改善の機会
    ○ github.com/jspecify で様々な議論を実施
    ○ ドキュメントの日本語化は、ある程度議論が落ち着いてからの予定
    ● リリースノートに記載の注意点
    ○ アノテーションをMaven Centralで公開しているが、1.0までに仕様を変更する可能性が高い
    ○ これを利用したライブラリをリリースしないように注意
    

    View Slide

15. まとめ：静的解析用標準アノテーションを作りたい
    ● JSR305は保守されず、Kotlinのような新しい技術が求める機能を持たない
    ● いたずらに”新標準”を作ると単に混乱を生むだけ
    ● コミュニティを巻き込んで合意を作り、使われる”最後の標準”を作りたい
    15
    

    View Slide

16. 参考資料
    1. JSpecify公式サイト (jspecify.dev)
    2. JVMLS19 overview presentation
    3. JSpecify v0.2.0 release note
    4. Eclipse FoundationによるJSR305を吸収する案
    16
    

    View Slide

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
    

    View Slide