File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes two string with same hashcode Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "two string with same hashcode" Watch "two string with same hashcode" New topic
Author

two string with same hashcode

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38107
    
  22
If you need big data, you create yourself a database, which is very good at storing and searching gigabytes of data.
drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61
Jeff Verdegan wrote:
You're missing the point. I might get Java 8 as soon as it's available, and build my app with it from day 1. If Java 9 changes hashCode() to a long, then I cannot use it without changing all my code--and all the code in every library I use. It's not just old stuff that breaks. It's anything from before the change.

if i know my app would get into trouble with compatability issues after i upgraded jre it's using, i might decide not to upgrade it, right? new features of the language in this case are not more important than keeping my app working normally. of course, from the supplier's standpoint, they always want to consider more for their large amount of users especially on the backward compatibility issue.




Not really. It's only 4 more bytes, which is at least an order or magnitude less than a lot of the objects it will be generated from anyway, and memory is cheap, and it's not like we typically keep large numbers of hashcode values around anyway. There are several compelling reasons not to change to an 8-byte hashCode(). Saving 4 bytes is not one of them.

yes, memory is cheap, but we should never waste it if we could save it, why not? (isn't the compelling reason "there's no need" currently?)

science belief, great bioscience!
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

drac yang wrote:
Jeff Verdegan wrote:
You're missing the point. I might get Java 8 as soon as it's available, and build my app with it from day 1. If Java 9 changes hashCode() to a long, then I cannot use it without changing all my code--and all the code in every library I use. It's not just old stuff that breaks. It's anything from before the change.

if i know my app would get into trouble with compatability issues after i upgraded jre it's using, i might decide not to upgrade it, right? new features of the language in this case are not more important than keeping my app working normally.


You're still missing the point, although you're stepping right in it.

If hashCode() were to change to long, a whole slew of existing apps wouldn't get the choice. They'd be stuck on their current version of Java, and completely unable to upgrade without a major rewrite, and having to wait for a bunch of libraries to upgrade is well, each of which may be waiting for libraries IT uses to upgrade. One of the key features of Java has been relatively painless upgrading of existing codebases to new versions. Changing hashCode() to long would break that completely, and there would be a huge divide between "old" Java apps and "new" Java apps, rather than the continuum we have now.

This is not to say that such a thing will never be done or should never be done, but there would have to be a very large benefit to doing so, and it would have to come from more philosophical shifts than just "more hash buckets."



Not really. It's only 4 more bytes, which is at least an order or magnitude less than a lot of the objects it will be generated from anyway, and memory is cheap, and it's not like we typically keep large numbers of hashcode values around anyway. There are several compelling reasons not to change to an 8-byte hashCode(). Saving 4 bytes is not one of them.

yes, memory is cheap, but we should never waste it if we could save it, why not? (isn't the compelling reason "there's no need" currently?)


No, it's not a compelling reason, and "never waste anything no matter what," fails when what you're "wasting" is so minuscule that it's worth less than the effort you have to go to not to "waste" it. You're missing the point here too, but I don't know how to explain it any better, so I'll just drop it.
drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61
Jeff Verdegan wrote:You're still missing the point, although you're stepping right in it.

If hashCode() were to change to long, a whole slew of existing apps wouldn't get the choice. They'd be stuck on their current version of Java, and completely unable to upgrade without a major rewrite, and having to wait for a bunch of libraries to upgrade is well, each of which may be waiting for libraries IT uses to upgrade. One of the key features of Java has been relatively painless upgrading of existing codebases to new versions. Changing hashCode() to long would break that completely, and there would be a huge divide between "old" Java apps and "new" Java apps, rather than the continuum we have now.

This is not to say that such a thing will never be done or should never be done, but there would have to be a very large benefit to doing so, and it would have to come from more philosophical shifts than just "more hash buckets.


jeff, first of all, thanks for your earnest reply.

it seems too much, i need to concentrate.

i nearly catch what you meant, you mean to let the old systems get the updates other than changes to long would be more advisable compared to only letting the new systems get the all updates including changes to long, right? because there're much more benefits waiting for the old system.

to be clear, there are two ways for comparison:

old apps together with new apps:
1. get updated
2. without changs to long (seems not serious for now and predictable near future, however admittedly, it's a trend eventually)

new apps:
1. get updated
2. with changes to long
3. old apps stuck in old version of java (similarly, i don't see too much harm, because originally they were built upon the old jdk, old apps amount might be huge though)

actually, i conclude it's just a choice of larger number of people to select which one of the two ways. no way is said to have to be selected.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: two string with same hashcode
 
Similar Threads
Java HashCode Problem
why hashcode same for String not for Class Object?
hashSet
How to convert String to int ?
How many objects are created?