Hi David, You are correct that the ZipFileInflaterInputStream code is not inherently thread-safe (without user synchronization), but then, the contract of InputStream does not require it to be (as Sherman previously observed on this thread).
The previous suggested fix caused ZFIIS to interact with the finalize thread, thus it had to care about being thread-safe at least to the extent of safe-guarding that interaction. As Sherman observed, and I agreed, finalization on that object is not really needed, so the inherent cross-thread interaction that would be introduced by the finalize method can be avoided in that case, and so the need to cater for inherent thread-safety can likewise be avoided. With the latest suggested change, if the ZFIIS is driven by multiple threads, it will be done at the user's (developer's) behest, so the user can (should) know to implement suitable synchronization to ensure correct behaviour. Therefore, I believe the same lack of synchronization in ZFIIS as there was in the previous anonymous inner class to be entirely justified in this case, given that it no longer has a finalize() method. Please let me know if you still disagree with this assessment, Thanks, Neil (Sent from my phone, so probably missing my usual signature)
