two string with same hashcode

[Campbell Ritchie]

If you need big data, you create yourself a database, which is very good at storing and searching gigabytes of data.

[drac yang]

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?)

[Jeff Verdegan]

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]

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.