fix: Correct Multiset example in TypeAdapterFactory Javadoc

[daguimu]

Problem

The TypeAdapterFactory Javadoc contains a MultisetTypeAdapterFactory code sample that does not work in practice. The factory uses typeToken.getRawType() != Multiset.class to check whether the type is a Multiset, but this identity check only matches the exact Multiset interface, not concrete implementations like HashMultiset or LinkedHashMultiset. As a result, the factory always returns null and Gson's built-in CollectionTypeAdapterFactory handles the type instead.

Root Cause

The raw type check uses != (reference equality) instead of isAssignableFrom, so it fails for all Multiset subtypes.

Fix

Change typeToken.getRawType() != Multiset.class to !Multiset.class.isAssignableFrom(typeToken.getRawType()), which correctly matches all Multiset implementations.

Impact

Documentation-only change. No runtime behavior affected.

Fixes #1335

[eamonnmcmanus]

Well, I don't know. The example maybe isn't great, but consider that if type instanceof ParameterizedType is true then the type must have come from some unerased context, like a field of type Multiset<String>, a call like gson.fromJson(input, new TypeToken<Multiset<String>>() {}), or delegation from another TypeAdapter. Your point about concrete types would only apply when those types are used instead of Multiset in these places, which I think would be somewhat unusual. You might also see those types when serializing based on the runtime type, like gson.toJson(myMultiset), but then Gson only has the erased type so type instanceof ParameterizedType will be false.

Maybe something like Optional would make for a better example, though. It's final, so the question of subclasses doesn't arise. The example could illustrate the better encoding described here, encoding Optional.of("foo") as just "foo" and Optional.empty() as null. We're likely to add support for Optional at some point, but it will use the clunkier encoding described in that comment.