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

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

I think that we should make the hashcode option default and bundle the 
commons-lang jar with Thrift. I find it confusing that it's something that has 
to be turned on, and even worse, once you turn it on, you have to go fetch a 
dependency that isn't described anywhere. 

It also makes running tests particularly uncomfortable, because the the 
build.xml for the test branch assumes that you have the jar in a specific 
location that's not guaranteed to exist on all machines. The common approach is 
to bundle jars needed for building and testing into a lib subdir.

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

Reply via email to