In May 1996, while preparing his second JavaWorld article, The Class File Lifestyle, Bill Venners opened a thread on comp.lang.java. He asked why the first four bytes of every Java class file are 0xCAFEBABE. This magic number gives tools a quick way to identify data that is likely to be a class file.

Early replies focused on hexadecimal wordplay. Rolf Howarth noted that the letters A through F leave few options for Java or coffee-related words. Alastair Mayer calculated the decimal value as 3405691582 and suggested that a 32-bit value would be practical and distinctive. He compared CAFE BABE with alternatives such as A FAB CAFE, CAFE FACE, CAFE A FAD and A BAD CAFE. Mayer also mentioned the Burroughs B6700, which used 0xBADBADBADBAD for 48-bit uninitialized memory. He later proposed 0xC0FFEE, or 0x00C0FFEE when written as a full 32-bit value, reading the zeros as O to produce OO COFFEE and a reference to object-oriented programming.

The discussion collected other examples of readable hexadecimal values. David N. Smith recalled an S/360 core dump where an out-of-range floating-point value happened to begin with 0xBAD. Paul Snively cited 0xDEADBEEF as a standard bogus value listed in The New Hacker’s Dictionary. He also described Macintosh debugging practice involving location 0, NIL! and 0x50FFC001. Vivian Man Cheng recalled 0xCAFEBABE in NeXTSTEP fat binaries, which combined binaries for different processors. David Harvey-George associated 0xFEEDFACE with Motorola and 0xCAFEBABE with Intel. James Lynn suggested possible coffee-shop inspiration and mentioned CAFEBEEF and DEADCAFE. Lee Crocker recalled IBM systems using 0xDEADBEEF, while William Halchin reported that AIX on RS6000 used 0xdeadbeaf for uninitialized storage.

Patrick Naughton provided the answer on 26 May 1996. The value had been chosen before the name Java was used for the language. The team wanted something fun, unique and easy to remember. 0xdeadbabe was the second runner-up. The connection with the coffee served at Peet’s Coffee was only a coincidence. Later replies added that IRIX arena files used 0xdeadbabe and that a debugging Solaris kernel filled kmemfree() blocks with 0xCAFEFEED.