POJO serialization vs immutability

I notice https://ci.apache.org/projects/flink/flink-docs-stable/dev/types_serialization.html#rules-for-pojo-types says that all non-transient fields need a setter. That means that the fields cannot be final. That means that the hashCode() should probably just return a constant value (otherwise an

Re: POJO serialization vs immutability

This question should only be relevant for cases where POJOs are used as keys, in which case they /must not/ return a class-constant nor effectively-random value, as this would break the hash partitioning. This is somewhat alluded to in the keyBy() documentation

Re: POJO serialization vs immutability

Hi Stephen, I found a very nice article [1], which might help you solve the issues you are concerned about. The elegant solution to this problem might be summarized as "do not implement equals() and hashCode() for POJO types, use Object's default implementation". I'm not 100% sure that this wi

Re: POJO serialization vs immutability

The default hashCode implementation is effectively random and not suited for keys as they may not be routed to the same instance. On 07/10/2019 14:54, Jan Lukavský wrote: Hi Stephen, I found a very nice article [1], which might help you solve the issues you are concerned about. The elegant s

Re: POJO serialization vs immutability

Exactly. And that's why it is good for mutable data, because they are not suited for keys either. Jan On 10/7/19 2:58 PM, Chesnay Schepler wrote: The default hashCode implementation is effectively random and not suited for keys as they may not be routed to the same instance. On 07/10/2019 14

Re: POJO serialization vs immutability

Having said that - the same logic applies to using POJO as keys in grouping operations, which heavily rely on hashCode() and equals(). That might suggest, that using mutable objects is not the best option there either. But that might  be very much subjective claim. Jan On 10/7/19 3:13 PM, Jan

Re: POJO serialization vs immutability

The POJOs that Flink supports follow the Java Bean style, so they are mutable. I agree that direct support for immutable types would be desirable, but in this case, we need to differentiate a bit more. Any mutable object can be effective immutable, if the state is not changed after a certain point

Re[2]: POJO serialization vs immutability

Sorry, but what about immutability in common? Seems like there is no way to have normal immutable chunks inside the stream (but mutable chunks inside stream seem to be some kind of «code smell»). Or I’m just missing something?   Best regards, Alex   >Понедельник, 7 октября 2019, 16:13 +03:00 от