[
https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610288#action_12610288
]
Todd Lipcon commented on THRIFT-68:
-----------------------------------
Absolutely agree. I should have clarified that I am 100% for a default "decent"
implementation that doesn't require the external dependency. I was just
disagreeing that we'd be better off removing the "return 0" which, despite
being a hack, is at least correct.
> 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.
