In this expression for hashCode:

there's a "& 0xFFFFFFFF". It's not very clear to me what the author's intent was, because if you did mask the value down to the lower 32 bits, that would be irrelevant anyway because the whole expressions gets cast to an int. But the "& 0xFFFFFFFF" is actually doubly irrelevant: 0xFFFFFFFF is the int value "-1", which gets upcast to the long value "-1", which is 64 1-bits, so there's no masking happening at all. But, like I said, the mask would be irrelevant either way ... possibly the author wanted to avoid a long addition and use only integer addition? In which case it could be rewritten to

return (int)(peer >>> 32) + (int)peer;

P.S. I only noticed this because, curious what the hashCode computed but too lazy to look up the source, I looked at the compiled bytecode instead, where it said:

 8 getfield com.sun.jna.Pointer.peer : long [6] 11 ldc2_w <Long -1> [3] 14 land 

which was of course very funny looking :)