Benefit from computing String Hash at compile time?

[James Arlow]

I'm not exactly up to date, but even reading entries from December, there are talks about computing the string hash at compile time.  This seems like a bad idea to me when looking towards future compatibility.

For the sake of posterity, it would make more sense to store the strings as literals in the class file, and then compute the hash during the class loading process.  The amount of processing at run-time would be negligible, and it would eliminate the possibility of errors creeping up from an "improved" or non-standard hash function.  

While the "improved" case seems unlikely, it would prevent whole sections of code from breaking simply because a third party JVM introduced an accidental error into the hash process. 

I think everyone can agree its best to not risk cutting off open options unless there is a critical performance penalty that would be addressed by doing so, so for a function that is called once per switch option and only when the class is loaded, I think its safe to forget about compile time hashes altogether.

If people are really worried about performance, then the best option would be to offer two ways to compile the class, one with string literals, for compatibility, and one with Java standard hash values, for performance.