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 <jaybo...@gmail.com> 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 protobuf@googlegroups.com.
> To unsubscribe from this group, send email to 
> protobuf+unsubscr...@googlegroups.com.
> 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 protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to