On Thu, 5 Jan 2023 04:59:51 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line
>> 130:
>>
>>> 128: @Override
>>> 129: protected int read(long fd, byte[] bs, int off, int len)
>>> throws IOException {
>>> 130: return VirtualMachineImpl.readPipe(fd, bs, off, len);
>>
>> If you add read/close methods for Windows that then call readPipe/closePipe,
>> then we don't need to subclass and override.
>
> Good suggestion.
> However, I wonder why the `fd` is casted from `long` to `int` on Unix. The
> Unix versions of SocketInputStream had `int fd`.
> So, the following code also needs to cast `fd` to `int`:
>
> + public synchronized int read(byte[] bs, int off, int len) throws
> IOException {
> + if ((off < 0) || (off > bs.length) || (len < 0) ||
> + ((off + len) > bs.length) || ((off + len) < 0)) {
> + throw new IndexOutOfBoundsException();
> + } else if (len == 0) {
> + return 0;
> + }
> + return read(fd, bs, off, len); <== ???
> + }
> +
> + public synchronized void close() throws IOException {
> + if (fd != -1) {
> + close(fd); <== ???
> + }
Looks like Windows needs a long fd so the shared API takes long and we then
cast to int for the Unix native methods. A little messy but fixable.
-------------
PR: https://git.openjdk.org/jdk/pull/11823
