New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address: Fix Java serialization and add serialization test case. #1036
Address: Fix Java serialization and add serialization test case. #1036
Conversation
Would this test actually have caught the issue? Surely the problem is a change in the schema, in which case you'd want to save a file to disk and load it in the test case to make sure it can still be deserialized? |
Emberassingly no, it's doesn't show the problem. It should – I'm not sure why it doesn't – need to investigate. What's gained by saving the byte array to disk and loading it back? That should not touch (de)serialization. |
What clearly shows the problem if I run the same test for MainNetParams. But then I thought rather than fixing serialization for NetworkParams we should make NetworkParams not support Java serialzation any more. It's quite trivial to "serialize" params by just remembering the ID, since NetworkParams are meant to be immutable and singleton. |
Sorry, Eclipse played a little joke on me. The issue is reproduable using the test:
|
Ah I see. You're just testing it can be serialized at all, not that it's compatible. OK that makes sense. Maybe you could add a test that verifies we can deserialize old bytestreams as well? Anyway the fix looks good. |
Afaicr we agreed that we don't support Java serialization as a persistence mechanism. Only for quick data exchange, e.g. between app components. |
Right, that's true. So this LGTM. |
The issue became uncovered because the newly-for-0.13 introduced HttpDiscovery.Details member into MainNetParams broke the serialization chain for all mainnet addresses.