Align VaporReference and ConcreteReference Nullability name() Formatting

オープン
  • 何か問題がありますか？
#13,798 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
java
領域
tooling

調査の方向性

gapic-generator-java モジュールの ConcreteReference.name()、VaporReference.name()、JavaWriterVisitor.visit(VaporReference) から始めて、nullable のフォーマットがどこで適用されているかを追跡します。nullable な内部クラスとジェネリック型の golden カバレッジを追加し、その後、ネストされた参照名が一貫してフォーマットされることを確認します。

索引モデルが issue の本文から書いたものです。

説明

priority: p3 type: feature request

Issue Details

There is a behavioral inconsistency in how JSpecify @Nullable annotations are prepended to class names between ConcreteReference and VaporReference in the gapic-generator-java AST. This technical debt is captured in the code via // TODO(miraleung): Give this behavioral parity with ConcreteReference.

  1. ConcreteReference.name() manually and dynamically prepends @Nullable to the class name if isNullable() is true: 
    if (isNullable()) {
  sb.append("@Nullable");
  sb.append(SPACE);
}
sb.append(simpleName());
  2. VaporReference.name() does not include this check in its name formation. Instead, nullability prepending for VaporReference was implemented purely inside the writer phase in JavaWriterVisitor.visit(VaporReference).

This inconsistency causes issues when reference names are dynamically constructed or compared (for example, when a VaporReference or ConcreteReference is nested as a generic parameter inside another reference, since the parent's build() method calls r.name() on its generics to build its own name string).

To unblock the initial JSpecify @Nullable PR, a temporary patch was applied to copy over the minimal behavior, but we need a clean, long-term alignment.

Proposed Follow-up Work:
  1. Add a dedicated golden test case capturing the behavior of nullable inner classes and generic types to ensure we prevent regressions.
  2. Refactor VaporReference and ConcreteReference to use a consistent representation of nullability formatting in name().
  3. Investigate if we can simplify ConcreteReference by removing the manual string formatting inside the AST class entirely, centralizing the nullability formatting logic inside the JavaWriterVisitor.

Environment

  • OS Type and Version: Linux
  • Java Version and JDK Vendor: Java 11+
  • Module: sdk-platform-java/gapic-generator-java

Dependencies

  • com.google.api:gapic-generator-java

Reproducer

The issue can be reproduced by comparing the string returned by name() for a nullable VaporReference vs a nullable ConcreteReference:

// ConcreteReference name will contain "@Nullable"
ConcreteReference.builder()
    .setClazz(String.class)
    .setIsNullable(true)
    .build()
    .name(); // Returns "@Nullable String"

// VaporReference name will NOT contain "@Nullable"
VaporReference.builder()
    .setName("MyClass")
    .setPakkage("com.google")
    .setIsNullable(true)
    .build()
    .name(); // Returns "MyClass"

This causes formatting differences when these references are nested inside collection types (e.g. List<@Nullable String> vs List<MyClass>).

主要言語
Java
スター
2.1k
フォーク
1.2k
平均マージ
2日 14時間
マージ済み PR（30日）
192

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

googleapis/google-cloud-java のほかの issue

googleapis/google-cloud-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。