Hi Jay, I encountered that before. Unfortunately this is a legitimate thing to do, as documented in Object.hashCode()
I have a write-up of the problem and how we wound up solving it (not elegant.. suggestions welcome) here: http://squarecog.wordpress.com/2011/02/20/hadoop-requires-stable-hashcode-implementations/ D On Mon, May 9, 2011 at 8:25 AM, Jay Booth <[email protected]> wrote: > I'm testing an on-disk hashtable with Protobufs and noticed that with > the java generated hashcode function, it seems to return a different > hashcode across JVM invocations for the same logically equivalent > object (tested with a single string protobuf, same string for both > instances). > > Is this known behavior? Bit busy right now backporting this to work > with String keys instead but I could provide a bit of command line > code that demonstrates the issue when I get a chance. > > Glancing at the generated hashcode() function, it looks like the > difference comes from etiher getDescriptorForType().hashCode() or > getUnknownFields().hashCode(), both of which are incorporated. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
