Yes, there is something bigger here. There was a thread on this long ago, but I can't find it.
It is never enough to add a serialVersionUID. If you add that, you also must define an explicit encoding (via writeReplace / readReplace, etc) that corresponds to the serialVersionUID. This is generally a lot of work and not as flexible as you want it to be. So my rationale on that ticket is a bit outdated, I think. We've basically made the decision not to try to support transmission between SDK or JDK versions that produce different serialVersionUID, which is the only use case for serialVersionUID since there is no protocol for compatible upgrade (other than just keeping the same serialVersionUID and doing best effort stuff in writeReplace/readReplace). At least in Beam (and arguably universally) Java serialization is just for transient sending from one machine to another where both machines are running identical code. That said, this indicates a potential problem so we'd want to get to the bottom of it. What Beam versions and JDK versions are involved? Kenn On Wed, Apr 20, 2022 at 2:21 AM Matt Casters <matt.cast...@neo4j.com> wrote: > Dear Beam, > > As part of our Java11 Hop source code upgrade I've come across a peculiar > error: > > org.apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl; local class > incompatible: stream classdesc serialVersionUID = -2577261693484760721, > local class serialVersionUID = 8033598657672506825 > > This class serialization issue is only happening on DataFlow and on Java > 11 for me. > I found https://issues.apache.org/jira/browse/BEAM-169 which seems to > warn against this particular scenario. > > Does it make sense to create a JIRA/PR for the one line addition of a > serialVersionUID for this particular class or am I missing something > broader in scope? > > Thanks! > > Matt > > >
