On Tue, 23 Aug 2022 18:57:07 GMT, Сергей Цыпанов <d...@openjdk.org> wrote:
> Suppose we have a scenario where `in` is replaced asynchronously in one of > implementations and the implementation is passed into constructor of > `DataInputStream`. In this case the patched code is less NPE-vulnerable, > isn't it? I can't imagine a subclass of DataInputStream setting 'in' to null. If it handles async close then it's possible that it replaces it with an input stream where read throws IOException unconditionally. This is why the original patch was problematic for the methods that call in.read in a loop. The updated patch is probably okay, I'm just pointing out that we are forced to think of subclasses when touching this code. ------------- PR: https://git.openjdk.org/jdk/pull/9956
