First of all, it is unlikely that you can compress a good hash in the normal sense. Compression is about a reversible encoding that reduces redundancy. In a good hash there should be no redundancy to reduce, and hence compression will be ineffective.
Since SHA-256 is 32 bytes long (256 bits), and I need it to fit into the serialVersionUID (64 bits), how might I convert it to a 64 bit value and minimize the loss of the characteristics of a good hash?
So what are those good characteristics? Well the primary characteristic of a good hash is that it is impractical to reverse it; i.e. it is impractical to work out a possible input that resulted in the hash. And a related characteristic is that given a known input that produces a given hash, it is impractical to produce another input (i.e. a collision) that gives the same hash.
Now when you go from a 256 bit to a 64 bit hash, you make it a whole lot easier to reverse a hash or produce a collision for a hash ... by brute-force. Basically, an 64 bit hash means there is one chance in 2^64 that any random input will have a given hash. That probability is large enough that some "bad guy" with enough cores has a good enough chance of success (in a reasonable time) to make brute-force a reasonable option.
But does it really matter? What would someone achieve by creating a serialVersion String that collides? These strings are not secret, and they don't tell you anything definitive about the API of the object ...
The bottom line is that if these reduced hashes are being used as serialVersion strings are designed to be used, then there won't be any problem in (for example) just using the first 64 bits of the SHA-256 hash. There is no need to XOR or checksum or do any other more complicated transformation.
