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.