Normally I have something like. String key = x + "." + y + "." + z; to make sure every object have it's own key.
Actually I would call it good enough, if it doesn't create a problem for you. You may use a StringBuilder to reduce created temporary Strings when doing String concatenation with +
StringBuilder keyBuilder=new StringBuilder();
If you are sure
you are using the StringBuilder from the same thread only, then you can even cache and reuse it when calling setLength(0) before:
static final StringBuilder keyBuilder=new StringBuilder();
int locationKey = x << y << z;
int recoloredSpriteKey = img.hashCode() << color.hashCode();
Using primitives as keys is a bad idea, because it will lead to a lot of autoboxing while using the hashmap (the java buildin Map implemtations need Objects as keys, so they will convert ints to Integers and back as needed, causing a lot of short lived objects and therefore garbage collection runs)
Other than that, the << operator shifts the left argument bitwise by the value of the right argument wrapping around, so what you listed above probably won't work, since e.g 64 shifted by 40 would result in the same key like 128 shifted by 39 etc.
So if you want to use this approachm you would need to go for something like
int locationKey = x*MAXIMUM_Y + y*MAXIMUM_Z + z;
int recoloredSpriteKey = img.someId * (256^3) + color.r*(256^2) + color.g*256 + color.b;
As you can see, your img-ids are limited to 256 values now and if you want to get the alpha value into the key, you are screwed anyway (or need to switch to long).
Now here comes, why lukasz1985 don't get your question. You didn't explain the use-case for which you need this key and the hashmap. If you want them for managing your objects, then you will probably be better of by just using names to identify them, because using the coordinates would mean the keys will constantly change when you move your object around the screen. If you don't need the keys for fast retrieval, then there is no point in storing the objects in a HashMap at all...
If you really need to and you want to avoid String keys, then a custom key object like Grunnt posted above would do the trick.
EDIT: And actually overriding the built in Object.hashCode() is a very bad idea - that solution will require that the elements stored is HashSet for example will have to immutable. Actually it's really evil idea....
Maybe this statement is out of context, but overriding the built in Object.hashCode() method (along with the equals() method) is exactly what you need to do when creating custom keys...
DO NOT MAKE UP YOUR OWN. TOSSING FUNCTIONS OF PRIME NUMBERS TOGETHER WILL SUCK.
Actually I would think it doesn't matter at all, because the amount of objects will be so small in the end that using an array and a brute-force search would be good enough anyway