search

GIScience / ohsome-api

API for analysing OpenStreetMap history data
https://api.ohsome.org
GNU Affero General Public License v3.0
47 stars 8 forks source link

default serial version UID vs. custom one #92

Open FabiKo117 opened 3 years ago

FabiKo117 commented 3 years ago

As discussed in https://github.com/GIScience/ohsome-api/pull/86#discussion_r555777233 there is currently no consistent way in the code whether there has to be a custom serial version UID for serializable classes, or not. We should decide for one of these two options and then stick to them throughout all serializable classes, unless there is a good reason for why to set a custom ID for specific classes (or not).

bonaparten commented 3 years ago

Actually explicit declarations of serialVersionUIDs are recommended.

tyrasd commented 3 years ago

That statement is of course true in general. But we are using object serialization quite differently than where it is normally used. We don't use it to actually send data to receivers we don't know, but rather only within a system that we control.

Also we use serialized lambdas quite a lot all over the place. For the (implicitly) generated classes for these lambdas we already have to trust the automatic UID computation to work an not make any problems. Until now we never had any issues with unexpected InvalidClassExceptions during deserialization.

I think the potential to introduce bugs in the future by forgetting to update the serialVersionUID field is more harmful than any benefits we would get from manually specifying it.

FabiKo117 commented 3 years ago

It is still not clear to me how to proceed: should we a) stick with the current code regarding this UID in the affected classes, or b) make it consistent throughout all classes, meaning removing the manually defined ones?

bonaparten commented 3 years ago

I would say to try to aim for consistency regardless of what solution we choose.