On Thu, 5 Jan 2023 05:44:23 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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.
> If you add read/close methods for Windows that then call readPipe/closePipe,
> then we don't need to subclass and override.
Sorry, I don't understand what this means. VirtualMachineImpl is
platform-dependent while HotSpotVirtualMachine is shared, we always need to
sub-class socket input stream in order to call platform-depend read/close.
-------------
PR: https://git.openjdk.org/jdk/pull/11823
