[...]

 That's why I was so insistent on it: Most people, when first seeing
this idiom, think they can somehow dispense with the loop. Even in the
most trivial cases, that is a grave error.

[I've taken the liberty to re-format your post to shorter lines.]

[...]

 BTW, while we're at it, anyone trying to write moderately complex
multi-threaded code and have it actually be correct and safe should have
an extra copy of Lea's excellent book under their pillow. Bloch's book
should be under any Java programmer's pillow anyway. ;-)

[...]

 No, the issue is that the underlying threading libraries, which Java
builds on, exhibit this behavior. The guarded wait idiom is exactly the
same in C as it is in Java. For example with pthreads:

   pthread_mutex_lock(&mut);
   while (x <= y) {
     pthread_cond_wait(&cond, &mut);
   }
   /* operate on x and y */
   pthread_mutex_unlock(&mut);

(Taken verbatim from my pthread_cond(3) man page.)

 The reason it is implemented that way is this: It would be possible of
course to ensure 100% correct behavior within the library, but doing so
would be so much extra effort that performance would suffer. So instead
a conscious design decision was made to allow for the small chance of
spurious wakeups and instead expect client code to only ever use guarded
wait loops. Note that this is not the only reason for using that idiom,
so the fact that the possibility of spurious wakeups forces you to use
it is not in any way a disadvantage. In fact, in the OpenGroup's SUS
(Single UNIX Specification) man page for the same group of functions
(that I posted a link to yesterday) this is explicitly mentioned, if
only in the informative section:

  `The effect is that more than one thread can return from its call to
   pthread_cond_wait() or pthread_cond_timedwait() as a result of one
   call to pthread_cond_signal(). This effect is called "spurious
   wakeup". Note that the situation is self-correcting in that the
   number of threads that are so awakened is finite; for example, the
   next thread to call pthread_cond_wait() after the sequence of events
   above blocks.

  `While this problem could be resolved, the loss of efficiency for a
   fringe condition that occurs only rarely is unacceptable, especially
   given that one has to check the predicate associated with a
   condition variable anyway. Correcting this problem would
   unnecessarily reduce the degree of concurrency in this basic
   building block for all higher-level synchronization operations.

  `An added benefit of allowing spurious wakeups is that applications
   are forced to code a predicate-testing-loop around the condition
   wait. This also makes the application tolerate superfluous condition
   broadcasts or signals on the same condition variable that may be
   coded in some other part of the application. The resulting
   applications are thus more robust. Therefore, IEEE Std 1003.1-2001
   explicitly documents that spurious wakeups may occur.'

http://makeashorterlink.com/?L1072278A

 (Ok, deciding to paste this makes my last paragraph above sort of
redundant. But perhaps it can't be stated often enough.)

 Now I can't claim to be sure that _all_ threading libraries Java uses
on _all_ platforms show this behavior, but 1. I suspect they do, and
2. it's enough that some do anyway. (Think portability.)