<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div> </div>
<div><span><font color="#0000ff" size="2" face="Arial">I 
still oppose this and see little point in it. Why guarantee something only to 
then say that noone should be acting based on the guarantee? What do you gain by 
this? The ability to change a while loop to an if-statement - and what does that 
gain you, a saving of  one comparison and one branch in a code block that 
suspends a thread ???</font></span></div></div></blockquote><div><br></div><div>As a practical matter, enough programmers have made the mistake (?) of depending on the current no-spurious-signal guarantee.  jsr166 has too many users to reverse this implementation decision now - it must be enshrined in the spec.  In fact, the jsr166 tck tests themselves are incorrect in making this assumption.  I considered "fixing" them, but I couldn't bring myself to weaken/complexify the tests when we could just go ahead and trivially fix the spec instead.</div>
<div><br></div><div>In cases where conditions represent irreversible state transitions, it seems not unreasonable to me to discard the loop, e.g.</div><div><div><br></div><div>        lock.lock();</div><div>        try {</div>
<div>            if (!isTerminated())</div><div>                termination.await();</div><div>        } finally {</div><div>            lock.unlock();</div><div>        }</div></div><div><br></div><div>the code will still work while being marginally more efficient, and there's probably lots of code out there depending on that.</div>
</div>