Probably one of the sweetest bugfixes is when you can solve random application freezes by rearranging the operands in the if() condition :)

if (isCondition1() && isCondition2()) {...} // freezes the app

if (isCondition2() && isCondition1()) {...} // works just fine

does isCondition1() send out blocking calls?

@alexbrooklyn yepp..

if (inputStreamIterator.hasNext() && readCount < expectedCount) { ... }

@netikras shouldn't you turn that one around?

Eit: Oh never mind I am stupid.

isCondition2 seems to be giving false in many cases, that's why blocking isCondition1 is dropped out

Though, if there is asynchronous version of isCondition1, I would recommend using it instead of synchronous one 💯

P. S.: Nevermind, if it's hasNext lagging, then it's ducked up on language level 😐

@vintprox it's ducked up on the library level ;)

And I don't agree with you about choosing async in if(). Async here will still have to be evaluated before moving on to another operand, so I'll have to wait for the synchronization to happen anyway.
Also, there are many different use-cases, where async might be not the right choice. Blindly claiming "use async everywhere" is not going to get one very far

@netikras I didn't clarify why asynchronous loop would be needed, well, because I don't particularly know your use case, and claiming that asynchronous is *always* better is no way for me, haha.
It could be useful if you had some more processing right after loop was started - but when possible, better do it beforehand, knowing that hasNext takes time 👐