The early bird gets the worm

I found one issue in correct code: After "interrupt" signal was sent, and reader.close() also executes, main thread finish it's execution, but few children threads freezes in "waiting data from BufferedReader" state, cuz them enters readLine right before interrupt signal was arrived. This causes main thread hands forever, until user enters few more lines, to let children threads process the interrupt then finish execution, only after that main thread will be closed with code 0. But I think the right way how it must to works is: after each thread prints out .toString(), program must be closed immediately. To archive that, we need to add one check right into while(!isInterrupted()), to achieve each thread non-blocking System.in read behavior:

while (!reader.ready()){
    Thread.sleep(200);
}

I had to change if (!string.isempty) to (string != null) to pass. It may not have any bugs, but some information that lines cannot be null would be nice to see in the conditions.

Task is not broken, and it does not run forever as long as you remember that the often underused 'return' statement can be used to exit a method once a condition has been met. So in the case of run() we could have IOException, and when we do get that, we can just return.

I'm not sure why this task (especially as a Hard-rated task) doesn't also have us write code to make sure the program ends after displaying the results. Seems like bad form to have the program just hang there waiting for more inputs that serve no purpose. Plus, if you actually did write code that would do this, the validation would fail, despite doing everything requested.

task1628 (The early bird gets the worm) undocumented requirement: the validation code seems to require that all threads continue reading even after the indicated number of words has been read. Translated to testing in IntelliJ this means that you have to hit Enter three additional times after having entered the correct number of word lines. If your code stops reading after the required number of word lines has been read then you will get failed on requirements 3 and 4 (and possibly 5 as well), without any indication what might be wrong, and even if your code clearly fulfills all these requirements.

while (count > readStringCount.get()) { } Why there is an empty while loop here?

There is no bugs in this task. The reason that if "fails" to stop running is because interrupt() does not stop a thread. All it does is set an internal boolean to true that you use for the while loop condition. The reason it is continuing in each case is because it is waiting for user input on the reader.readlin() method, which is unaffected by the "interrupt". When all those lines finish reading data, and the while loop is broken, then the program will complete. Also, reader.readline() can return null, which means nothing was read. This should not be put in the ArrayList of items that were read - if nothing was read then nothing should be added

I came to the comments to see how to stop my program from running, as I assumed that this would cause me to fail verification. Instead, I read that I needed to add an if statement to check if input was null. Thanks, guys! I passed on the first try, even if my program never stops running!

This one would not be too difficult to pass if we did not have to ensure that Strings that follow after "count" variable should be tested for NULL value. CodeGym please fix this or add this as requirement.

Ik think there is a bug in this task. I copied the answer but it had the same problem. It passes the test but fails to stop the programm It just keeps running.