Fix comment in Converter.
Converter.apply is annotated as returning null, so it's sound. The LegacyConverter problem arises only if users view the converter as a Function<A, B>, since Function<A, B>.apply is *not* annotated as returning null (and yet a LegacyConverter may do so, even given a non-null input).
RELNOTES=n/a
PiperOrigin-RevId: 368219982
diff --git a/android/guava/src/com/google/common/base/Converter.java b/android/guava/src/com/google/common/base/Converter.java
index bc8a05c..208a032 100644
--- a/android/guava/src/com/google/common/base/Converter.java
+++ b/android/guava/src/com/google/common/base/Converter.java
@@ -234,11 +234,11 @@
* methods as implementations of normal converters do?
*
* But no matter what we do, it's worth remembering that the resulting code is going to be unsound
- * in the presence of LegacyConverter, at least in the case of Converter.apply and convertAll (and
- * for any checkers that apply @PolyNull-like semantics to Converter.convert). So maybe we don't
- * want to think too hard about how to prevent our checkers from issuing errors related to
- * LegacyConverter, since it turns out that LegacyConverter does violate the assumptions we make
- * elsewhere.
+ * in the presence of LegacyConverter, at least in the case of users who view the converter as a
+ * Function<A, B> or who call convertAll (and for any checkers that apply @PolyNull-like semantics
+ * to Converter.convert). So maybe we don't want to think too hard about how to prevent our
+ * checkers from issuing errors related to LegacyConverter, since it turns out that
+ * LegacyConverter does violate the assumptions we make elsewhere.
*/
@CheckForNull
diff --git a/guava/src/com/google/common/base/Converter.java b/guava/src/com/google/common/base/Converter.java
index bc8a05c..208a032 100644
--- a/guava/src/com/google/common/base/Converter.java
+++ b/guava/src/com/google/common/base/Converter.java
@@ -234,11 +234,11 @@
* methods as implementations of normal converters do?
*
* But no matter what we do, it's worth remembering that the resulting code is going to be unsound
- * in the presence of LegacyConverter, at least in the case of Converter.apply and convertAll (and
- * for any checkers that apply @PolyNull-like semantics to Converter.convert). So maybe we don't
- * want to think too hard about how to prevent our checkers from issuing errors related to
- * LegacyConverter, since it turns out that LegacyConverter does violate the assumptions we make
- * elsewhere.
+ * in the presence of LegacyConverter, at least in the case of users who view the converter as a
+ * Function<A, B> or who call convertAll (and for any checkers that apply @PolyNull-like semantics
+ * to Converter.convert). So maybe we don't want to think too hard about how to prevent our
+ * checkers from issuing errors related to LegacyConverter, since it turns out that
+ * LegacyConverter does violate the assumptions we make elsewhere.
*/
@CheckForNull
