4 ms·

Your characterization of "hidden state" doesn't make a lot of sense. Either a state is part of the object's identity, and it's serialized, or it's not, and it'

Your characterization of "hidden state" doesn't make a lot of sense. Either a state is part of the object's identity, and it's serialized, or it's not, and it's not. This observation has nothing to do with data classes, records, Java, or Kotlin. > The result will be equal in the `equals` sense, but the resulting object will not be substitutable for the original. This doesn't make sense either. You are describing someone who implemented flawed serialization. It's a programmer error, not a language or semantic one. I see very little difference of practical importance between Java's records and Kotlin's value classe, and as much as I value your technical writings, I am concerned that your employer is tainting your objectivity when trying to compare Java and Kotlin. You can do better.

pron 4y ago
What's serialised is not identity but state. If any part of the state is hidden, i.e. serialization needs to set it not via the object's public API, then serialization can break the object's invariants. This is what serialization vulnerabilities are. You certainly can write classes with safe serialization, but serialization vulnerabilities happen because sometimes people don't. Sure, it's an error, but it is one of the errors that enums and records were created to avoid. But it is true that we can live without records and enums, and, indeed, we did, so I wouldn't say they're critical features. Still, I think it's important that people know that records and enums -- unlike data classes, which are syntax sugar -- were added for the guarantees they make regarding certain behaviours, including interaction with collections and with serialization (of any kind).
- hota_mazi 4y ago
  > What's serialised is not identity but state. These are not mutually exclusive and they describe actually two very different concepts. If your objects will end up in a hashing container, you absolutely need to serialize what makes their identity. If not, you can serialize whatever you need from the object. It can be more fields than its identity, or fewer. I'm not sure what your following point about serialization vulnerability (however correct) has to do with the current discussion.

pron 4y ago

What's serialised is not identity but state. If any part of the state is hidden, i.e. serialization needs to set it not via the object's public API, then serialization can break the object's invariants. This is what serialization vulnerabilities are. You certainly can write classes with safe serialization, but serialization vulnerabilities happen because sometimes people don't. Sure, it's an error, but it is one of the errors that enums and records were created to avoid. But it is true that we can live without records and enums, and, indeed, we did, so I wouldn't say they're critical features. Still, I think it's important that people know that records and enums -- unlike data classes, which are syntax sugar -- were added for the guarantees they make regarding certain behaviours, including interaction with collections and with serialization (of any kind).

hota_mazi 4y ago
> What's serialised is not identity but state. These are not mutually exclusive and they describe actually two very different concepts. If your objects will end up in a hashing container, you absolutely need to serialize what makes their identity. If not, you can serialize whatever you need from the object. It can be more fields than its identity, or fewer. I'm not sure what your following point about serialization vulnerability (however correct) has to do with the current discussion.