Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] Major/Minor updates in EclipseLink

Hello all!
I have noticed over the years that we have a lot of Serializable classes that don't have SerialVersionUIDs. For WebSphere/Open Liberty, we check for minor/major updates to EclipseLink with each fixpack release and flag those changes for internal review. We want to make sure that customers using EclipseLink 2.7.1 (our Liberty 18.0.0.2) can safely update to 2.7.3 (our 18.0.0.3) without breaking backwards compatibility. We do this by comparing the new and old Serial IDs for API packages/classes we export.

Unfortunately, some Serial IDs have been missing in EclipseLink for a long time and default Serial ID generation is being used. When I updated us to 2.7.3 recently, we get all the new generated Serial IDs and compare them with what we had before (2.7.1). Changes in the Serial ID are then flagged as breaking/major changes for us. See this link for what those entail: https://docs.oracle.com/javase/6/docs/platform/serialization/spec/version.html#6678

Most of these changes are actually minor changes which are perfectly fine, but since we are using default Serial ID generation, it looks like a major change :(

For master/ECL 3.0, I would love to see a mass generation of Serial IDs for serializable classes. For service branches (2.7, 2.6, ect), I think it is important to understand what breaking changes are so that we can all try to not deliver these kinds of changes, like generating new IDs. If a new ID should be generated, because a major change is being made, then that should prompt you to not make the change. We don't want to break backwards compatibility in service branches.

At the moment, our process has flagged 15 major/breaking changes between 2.7.1 -> 2.7.3. I have traced down these changes and found that most of them were flagged because the SerialVersionUID changed, and all those changes were actually minor ones (new methods were added). In these cases, we should have had a serialVersionUID that was just not updated to signify a compatible change.

This email is meant to start a conversation so if anyone wants to point out how wrong I am, please let me know :) Also, I'd like to know if we can look into this for 3.0

Thanks,
Will Dazey
 

Back to the top