[
https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036285#comment-13036285
]
Greg Moulliet commented on THRIFT-68:
-------------------------------------
Given that Thrift supports Sets and Maps, and in Java uses HashSet and HashMap,
it is particularly surprising to me that the default hashcode performs so
poorly for Set and Map serialization, O(n^2).
> 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: Java - Compiler, Java - Library
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
