$30 off During Our Annual Pro Sale. View Details »

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

    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