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.
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.
science belief, great bioscience!
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.
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 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.
science belief, great bioscience!