Boolean.hashCode()

1231 and 1237 are just two (sufficiently large) arbitrary prime numbers. Any other two large prime numbers would do fine.

Why primes?
Suppose for a second that we picked composite numbers (non-primes), say 1000 and 2000. When inserting booleans into a hash table, true and false would go into bucket 1000 % N resp 2000 % N (where N is the number of buckets).

Now notice that

• 1000 % 8 same bucket as 2000 % 8
• 1000 % 10 same bucket as 2000 % 10
• 1000 % 20 same bucket as 2000 % 20
• ....

in other words, it would lead to many collisions.

This is because the factorization of 1000 (2³, 5³) and the factorization of 2000 (2⁴, 5³) have so many common factors. Thus prime numbers are chosen, since they are unlikely to have any common factors with the bucket size.

Why large primes. Wouldn't 2 and 3 do?
When computing hash codes for composite objects it's common to add the hash codes for the components. If too small values are used in a hash set with a large number of buckets there's a risk of ending up with an uneven distribution of objects.

Do collisions matter? Booleans just have two different values anyway?
Maps can contain booleans together with other objects. Also, as pointed out by Drunix, a common way to create hash functions of composite objects is to reuse the subcomponents hash code implementations in which case it's good to return large primes.

Related questions:

• Why use a prime number in hashCode?
• What is a sensible prime for hashcode calculation?
• Why does Java's hashCode() in String use 31 as a multiplier?

In addition to all that's said above it can also be a small easter egg from developers:

true: 1231 => 1 + 2 + 3 + 1 = 7

7 - is a lucky number in European traditions;

false: 1237 => 1 + 2 + 3 + 7 = 13

13 (aka Devil's dozen) - unlucky number.