[jira] Commented: (THRIFT-68) Generated types define a hashcode method that always returns 0

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711247#action_12711247 ] 

Bryan Duxbury commented on THRIFT-68:
-------------------------------------

Since we've begun using ivy for dependency resolution, would it make sense to rethink this issue? We could remove the hashcode option and always generate a respectable hashcode implementation using the commons-lang hashcode builder. 

> 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.