com.google.common.collect.Range#hasLowerBound determination error after deserialization

[YongwuHe]

Description

after I serialize a Range object, I get the Range object through json deserialization. The new Range object hasLowerBound returns true. Because the judgment of this method is lowerBound != Cut.belowAll()

Example

range2 = Range.lessThan(2);
final String range2Json = GsonSerializer.INSTANCE.serialize(range2);
final Range deserializeRange2 = GsonSerializer.INSTANCE.deserialize(range2Json, Range.class);
assertEquals(range2.upperEndpoint(), deserializeRange2.upperEndpoint());

Expected Behavior

assertFalse(range2.hasLowerBound());
assertFalse(deserializeRange2.hasLowerBound());

Actual Behavior

assertFalse(range2.hasLowerBound());
assertTrue(deserializeRange2.hasLowerBound());

Packages

com.google.common.collect

Platforms

No response

Checklist

• I agree to follow the code of conduct.

[cpovirk]

Since GsonSerializer is creating the Range object, you'll have to identify who is responsible for that code and figure out how it's serializing and deserializing the new range. GsonSerializer isn't part of Guava, so we don't have control over that.

[YongwuHe]

Since GsonSerializer is creating the Range object, you'll have to identify who is responsible for that code and figure out how it's serializing and deserializing the new range. GsonSerializer isn't part of Guava, so we don't have control over that.

ex:
public boolean hasLowerBound() { return lowerBound != Cut.belowAll(); }
When the lowerBound object is deserialized, although it is still of type com.google.common.collect.Cut.BelowAll, since it is a re-created object, it will not be equal to Cut.belowAll(). So I think this judgment is not accurate enough. Would it be more accurate to use the following judgment?
public boolean hasLowerBound() { return ! (lowerBound instanceof BelowAll) ; }
@cpovirk

[cpovirk]

If GsonSerializer is creating extra instances of private classes by using reflection to override visibility rules, then your suggestion would probably fix the problem you're seeing. But that is an approach that I would not want to encourage: Such reflection may cause many other such problems, and I don't want to give users false hope that it will work in general or that we're doing any kind of testing or planning to make that happen.

[YongwuHe]

If I need to pass the Range type when requesting the external interface, I first need to serialize the Range into JSON and send it to the server. Upon receiving the JSON, the server needs to deserialize it to obtain the correct Range type and perform the corresponding logical processing. However, this scenario becomes impractical because the deserialization process requires the object to be regenerated
@cpovirk

[cpovirk]

It sounds like GsonSerializer needs to serialize and deserialize a Range object manually instead of using reflection. That probably means that it will need to change to use a custom serializer for Range.

[YongwuHe]

This workaround may necessitate extra effort from the user. I think as a tool class, it is crucial to consider its convenience for users across different scenarios and its compatibility with various use cases.

[cpovirk]

Reflection is definitely sometimes a quick way to get things working. However, since it depends on the implementation details of the library you're reflecting on, it often leads to breakages down the line. (For example, it's usually one of the main obstacles to JDK upgrades.) So the convenience and compatibility today may lead to inconvenience and incompatibility later on.