• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
Sheriffs:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
Bartenders:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

two string with same hashcode

 
Marshal
Posts: 68075
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you need big data, you create yourself a database, which is very good at storing and searching gigabytes of data.
 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?)
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

 
rubbery bacon. rubbery tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!