When I uncomment the last lines, I only get one or two results (out of 3000 or so). The rest never print even though the run method is called (started) on a new StreamEater each time through the loop. I don't understand why. How can I close my PrintWriter without this problem?
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
PrintWriter.close(), like all good Writers, calls close() on the underlying stream. If you wrap a PrintWriter around System.out then closing it will close System.out -- not usually what you want. Once System.out is closed, it's gone -- no more output.
Since sometimes StreamEater should close the PrintWriter (assuming sometimes 'os' isn't System.out), and sometimes not, there are several different ways you could go. You could give StreamEater a boolean flag/constructor argument telling it whether the stream should be closed or not. Or you could move the responsibility for closing the stream to the class that constructs the StreamEater (tricky due to threads).
Or, since PrintWriter is always a "derived" stream, you could never close it; just flush it, and let the constructing code manage 'os'.
You can't. Closing a PrintWriter (or any PrintStream, FilterWriter, FilterReader, or FilterXXXStream) has the effect of closing the underlying stream. The docs aren't 100% clear here (they just say it "releases any resources") but that's what happens.
I would say that your StreamEater really shouldn't close the PrintWriter here, because that closes the underlying os stream. StreamEater did not create this stream, and is not in a position to "know" whether it's OK to close that stream now or not. StreamEater should just flush the PrintWriter, and let whoever created the stream decide what to do with it later. In this case that's ClassFinder, which should close the FileStream just once after all the others are done with it.
That may seem odd to intentionally not close the PrintWriter in the class that created the PrintWriter. But the PrintWriter doesn't have any resources that need to be freed, except for (a) it needs to be flushed, and (b) the underlying stream may need to be closed.
I once had a situation where some other code outside my control was closing a stream I had sent it, and I needed to prevent that. I overrode FilterWriter to create a NonclosingFilterWriter which I used as a decorator around the stream I needed to protect. I overrode close() to simply have no effect. Possibly you might do something like that here if you have problems with other code closing something it shouldn't. But as long as you control all the pertinent code, that shouldn't be necessary.