Kubernetes-client: Why KubernetesResource extends Serializable?

[jorsol]

Is there any need for KubernetesResource to extend Serializable?

I think the Serializable could be dropped since Jackson handles the de/serialization here, or is there any other use for this?

[rohanKanojia]

@manusa @oscerd : What do you think about this? Shall we drop the Serializable interface?

[manusa]

Is there any specific reason why we don't want to keep the Serialization implementation?

I'm not sure if any user is actually making use of standard Java serialization AP and would be affected by this.

IMHO is a good practice to make classes that are to be serialized in one way or another implement the Serialization interface (I usually even go one step further and even add the serialVersionUID field...).

[jorsol]

Is there any specific reason why we don't want to keep the Serialization implementation?

I'm not sure if any user is actually making use of standard Java serialization AP and would be affected by this.

IMHO is a good practice to make classes that are to be serialized in one way or another implement the Serialization interface (I usually even go one step further and even add the serialVersionUID field...).

IMHO Java standard serialization is not a good fit here and I doubt that any user is actually making use of it.

And as you said, you go one step further and add the serialVersionUID field (I also do it), but that's is mostly useless for Jackson.

The main issue that leads me to open this issue, is that we have many classes that extends CustomResource (HasMetadata -> KubernetesResource -> Serializable), and in turn they have POJOs like Spec, Status, etc, and in turn they have other POJOs... so to make the IDE and static analyzers happy, every single class needs to implement Serializable (and serialVersionUID) for no good reason.

But don't take my word for it... from Brian Goetz, Java Language Architect:
https://cr.openjdk.java.net/~briangoetz/amber/serialization.html

Just to quote one paragraph from the article:

On the other hand, Java's serialization makes nearly every mistake imaginable, and poses an ongoing tax (in the form of maintenance costs, security risks, and slower evolution) for library maintainers, language developers, and users.

[manusa]

Yep, I get your point. As I said I'm not sure if anyone else may be affected by the removal of the interface.

e.g. It's been a long time since I used Apache Wicket, but I know for sure it would cause an issue (at least back in the day) if someone was persisting any KuberentesResource instance in their session.

Let's see if we can get more input on this one.

[jorsol]

Oh, I get it, yep someone that persists any KuberentesResource in their session could have some issue.

Sadly I think it would be hard to get more input on this one, anyway, let's wait until the stale bot close this.

[manusa]

Related to: https://github.com/fabric8io/kubernetes-model/pull/177

Serializable interface was added around a year after the project for _some reason_.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!