Standardize serialVersionUID generation than random

[techpavan]

I have a project with multiple types and each time a minor change is made in the RAML and generate the code, all the POJOs get regenerated. Though the content of POJOs are same, it just comes up on the change list due to change in serialVersionUID forcing me to take an action - either commit or revert. It would be great if this can be handled by handing over the responsibility of serialVersionUID generation to standard Java packages rather than using a random long.

This can be done using the serialver command or objectStreamClass.getSerialVersionUID()

• https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html
• https://docs.oracle.com/javase/7/docs/api/java/io/ObjectStreamClass.html#getSerialVersionUID()

[stojsavljevic]

Out of curiosity, why do you keep generated code in source control?

[techpavan]

This development scenario involves the same RAML being developed into multiple services - related, but disconnected. Client can consume multiple such services. If RAML file is being checked in to each such repository and generated code is built as a part of build process, it might lead to a case when one or few of the repos are out of sync. Thus, we maintain RAML and its documentation generated with raml2html in one repository, generated code is in a different repository and built artifacts pushed into the artifactory which is consumed as a maven dependency.

[stojsavljevic]

Can you consider a PR?

[techpavan]

Will give it a try.

[tburny]

I'm running into the same issue. Can't we simply skip writing the generated source file if only the serialversionuid was changed?

[stojsavljevic]

It will be hard to detect if there are some other changes but serialVersionUID.
What about solution that @techpavan suggested?
Another option might be to generate default serialVersionUID (config option) so POJOs remain the same.
wdyt?

[tburny]

If the class changes, so should the serialVersionUid. Vice versa, if the class does not have any changes, it should not be regenerated.

I would suggest a bit of a "hacky" solution here:

1. If the target file already exists, read it.
2. Strip the target file contents of the serialVersionUID value
3. Strip the generated java source code of the serialVersionUID value
4. Overwrite the target file only iif the contents (minus the header and generation timestamps) are not identical.

[stojsavljevic]

That's a real "hacky" solution.
Do you have some other idea?
What about objectStreamClass.getSerialVersionUID() as @techpavan suggested?

[tburny]

I added the required code (see PR).

Notes:

• instead of fixing all the test reference files I simply fixed the "removeSerialVersionUID" test code :)
• I did not test running the generated code in a real scenario yet

[stojsavljevic]

objectStreamClass.getSerialVersionUID() doesn't do the job as it returns serialVersionUID - it doesn't generate it.

[tburny]

Actually it does, if you take a look at this stack overflow question: https://stackoverflow.com/questions/18294326/how-to-generate-serialversionuid-programmatically-in-java and this answer specifically https://stackoverflow.com/a/18294506/812272

However I have a feeling that the serialVersionUID is not required at all and we are barking up the wrong tree.

serialVersionUID is not needed when (de)serializing java objects to JSON (as per https://stackoverflow.com/questions/27738757/can-serialversionuid-be-ignored-when-serializing-to-json).
The plugins purpose is to generate controllers, clients and POJOs for data transfer. Inherently this means the objects transferred are

• language agnostic (a controller class can be called i.e. from a web browser) - there is no serialVersionUID in other languages
• not meant to be persisted (and thus the java objects should not be serialized using ObjectStreamClass and friends) - if you do, then the application's architecture is terribly broken
• JSON is only about fields and data, not classes, methods, etc.
• Serialized classes are not sent over the network, as it contradicts the idea of RAML and REST

For that reason I'd vote for removing the serialVersionUID and the Serializable marker interface completely.

[stojsavljevic]

Still, some people prefer to have serialVersionUID so I will propose:

• making serialVersionUID optional (config param)
• introduce logic to generate serialVersionUID. If the answer to that stackoverflow question is correct, we should use it. Otherwise, we can come up with our custom logic based on POJO's full name, methods' signatures etc to generate some kind of hash and get consistent uid.

Please consider a PR(s) if this makes sense for you.