You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2008/07/03 18:59:45 UTC

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

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

Todd Lipcon commented on THRIFT-68:
-----------------------------------

I disagree here. The default generator *does* generate a proper .equals() method which determines object value equality. The default implementation of Object.hashCode() returns a value based on the object reference, not the object value. Therefore, if we were to not implement hashCode() we would break the contract that a.hashCode() == b.hashCode() if a.equals(b).

Always returning 0 is not terribly smart, since everything will hash to the same bucket and give hash-based containers O(n) lookup performance, but it's better than nothing, which would give them incorrect semantics.

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