Why Using Fixed Seeds with Java Random Prints "Hello World"

The author discovered a StackOverflow question where a Java program prints "hello world" by concatenating two strings generated with Random objects seeded with the fixed integers -229985452 and -147909649 . By running the code, the output is consistently "hello world".

The key is that new Random(seed) creates a pseudo‑random generator that produces the same sequence of numbers for the same seed. The Javadoc states that two Random instances with identical seeds and identical method call sequences will return identical number sequences.

A second snippet demonstrates this determinism by calling randomString(seed) twice with the same seed and printing the intermediate nextInt() values, showing identical results on every run.

The method randomString builds a string by repeatedly calling ran.nextInt(27) . When the returned value is zero the loop ends; otherwise the value is added to the character '`' (ASCII 96). This maps numbers 1‑26 to the letters a‑z (ASCII 97‑122), so the generated characters form readable words.

By examining the first few numbers produced by the two seeds, the article maps them to the letters h, e, l, l, o, w, o, r, l, d, revealing how the fixed seeds encode "hello world".

Extending the idea, the author provides a generateSeed method that brute‑forces a seed capable of producing any desired phrase (e.g., "the quick brown fox...") by iterating over a range of seed values and comparing the generated characters to the target string.

The brute‑force search can be time‑consuming; the author notes a run that took over 70 hours without finding a seed for a longer phrase, illustrating the exponential cost as the target word length increases.

Beyond the specific example, the article dives into the Java Random source code, pointing out two "magic numbers" used in the seed generation algorithm and a historical copy‑paste error that omitted a leading "1" in the constants, leading to reduced randomness when new Random() is called concurrently.

References to related StackOverflow discussions and an OpenJDK bug report are provided, showing how the issue was identified and corrected in later JDK releases. The author concludes by recommending the modern ThreadLocalRandom class for better performance and randomness.