Hi Gary,
I think overall it would be better to fix the InputStream to be tolerant to
multiple calls to close, as Ralf pointed out. Maybe someone else on some other
place runs into this again because he/she relies on the correct implementation
of Closeable.
However, as a quick fix I can also im
Hi,
looking at the source code, all Unix variants use the same unsafe code in the
close method of the returned InputStream. On Windows there is already a check,
but it is not synchronized.
Best regards,
Ralf
Hi,
> So you prefer the fix in VirtualMachineImpl SocketInputStream close()
> rather than the JCmd try with resources.
Yes, since the close() method is not spec conform. I think it is better to fix
it than to adjust the code using it. Especially if you consider that the
current behavior could b
So you prefer the fix in VirtualMachineImpl SocketInputStream close()
rather than the JCmd try with resources.
If we were dealing with output streams, it would be important
to apply the flush to the writer. Since these are input
streams we just need to guard against the duplicate close
for the na
Hi,
since InputStream imeplements Closeable, calling close multiple times *must*
work:
public interface Closeable extends AutoCloseable {
/**
* Closes this stream and releases any system resources associated
* with it. If the stream is already closed then invoking this
* meth
The workaround below passed 1000 testruns on linux-x64-debug.
A more localized fix simply moves the stream reader out of the
try with resources, so only one close is applied to the underlying
socket. I'll run this test through 1000 testruns today.
Looking for a final review for this change.
dif
