You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2008/07/03 18:45:45 UTC
[jira] Created: (THRIFT-68) Generated types define a hashcode
method that always returns 0
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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711452#action_12711452 ]
David Reiss commented on THRIFT-68:
-----------------------------------
I'm still okay with turning it on by default. I would like to still have the option to disable it.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610280#action_12610280 ]
Bryan Duxbury commented on THRIFT-68:
-------------------------------------
Returning 0 to satisfy the semantics is a hack. Why don't we just make a hashcode function that is the composition of the object's member's hashcodes? Then we could have both correct equals semantics and hash containers that actually work.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787628#action_12787628 ]
Jonathan Ellis commented on THRIFT-68:
--------------------------------------
thanks both for the clarifications.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638166#action_12638166 ]
David Reiss commented on THRIFT-68:
-----------------------------------
I'm fine with turning on by default, though it doesn't seem as critical to me as to you. I don't think we should start down the road of bundling external libraries with Thrift, though. You are correct that we would have to document the dependency better if we made it a default.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787607#action_12787607 ]
David Reiss commented on THRIFT-68:
-----------------------------------
Jonathan, in case it isn't clear, generate your code with "--gen java:hashcode" and you will get a better hashCode implementation. You will also need to make sure apache commons lang is available.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610304#action_12610304 ]
David Reiss commented on THRIFT-68:
-----------------------------------
Everything in Todd's first comment is correct. Returning 0 is correct but slow, and we had to do it once we implemented .equals(). Personally, I don't think we should waste time reimplementing something something that is in a library of "stuff that should be in java.lang, but isn't", but if someone submits a patch for this, which does not give a false sense of quality, I will grudgingly commit it.
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787559#action_12787559 ]
Jonathan Ellis commented on THRIFT-68:
--------------------------------------
Bryan, your last comment was about using apache commons to generate a hashcode but then you closed as wontfix; could you explain what changed your mind?
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787593#action_12787593 ]
Bryan Duxbury commented on THRIFT-68:
-------------------------------------
I decided the benefit of removing the option or making it default to on didn't merit the effort. I'd be willing to rethink it if someone else wants to chime in.
> 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.
[jira] Closed: (THRIFT-68) Generated types define a hashcode method
that always returns 0
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury closed THRIFT-68.
-------------------------------
Resolution: Won't Fix
> 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.
[jira] Commented: (THRIFT-68) Generated types define a hashcode
method that always returns 0
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ 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.