[
https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610304#action_12610304
]
David Reiss commented on THRIFT-68:
-----------------------------------
Everything in Todd's first comment is correct. Returning 0 is correct but
slow, and we had to do it once we implemented .equals(). Personally, I don't
think we should waste time reimplementing something something that is in a
library of "stuff that should be in java.lang, but isn't", but if someone
submits a patch for this, which does not give a false sense of quality, I will
grudgingly commit it.
> Generated types define a hashcode method that always returns 0
> --------------------------------------------------------------
>
> Key: THRIFT-68
> URL: https://issues.apache.org/jira/browse/THRIFT-68
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (Java), Library (Java)
> Reporter: Bryan Duxbury
> Priority: Minor
>
> When not using the "hashcode" option with the Java generator, the hashCode
> method that is created always returns 0, regardless of the type or instance.
> This makes it completely impossible to use as a hash key (or in a hash set).
> This is particularly curious because the default Java Object#hashCode method
> returns a reasonably unique hashcode per object instance. Thus, the hashCode
> method on generated types is actually explicitly worse than default.
> I think at the very least we should remove the hashCode method declaration
> and let the superclass method take care of it. At best, I think it would make
> sense for us to write a simple real hashCode method that produced something
> reasonably unique, if not perfect. If you need super hashCodes, then you can
> use the "hashcode" option and just plan on using the external jar that it
> requires.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
