I have a case where a thread can finish in 3 ways:
3) when I interrupt the thread (thread.interrupt()).
This assumption is wrong, there is at least a forth way the thread can finish: When something else interrupts the thread. Spurious interrupts are real and allowed the JLS. If your code uses interrupt for control flow, you always have to check a second condition to determine the interrupt cause.
Yes, the InterruptedException is logged instead of thrown, which is bad practice.
I beg to differ, at least in this case. The API was designed to accommodate the use cases most of most users: Receive a reply or await the timeout. It therefore guarantees that only one of two things will make the method return: A packet arrives *or* the collector has waited the *whole* timeout value. Exposing the InterruptedException to the user would also tempt those to write wrong code, by assuming that the InterruptedException can only be caused by them calling interrupt().
If you have a third option that could happen while using an IQ, then you should consider using Smack's async API.
I don't think nextResultUninterruptibly is needed. If the user does not care he can just ignore the exception.
Which would also mean adding InterruptedException to every method in Smack and user code that calls the method, or wrapping the checked exception into a unchecked one. Those are not good solutions imo.
andrelab Consider using Smack's async API (sendIqWithResponseCallback() and Co) here.