RFR: JDK-8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE
Lance Andersen
lance.andersen at oracle.com
Thu Apr 9 22:08:53 UTC 2020
Hi Mark,
Thank you for the feedback.
> On Apr 9, 2020, at 4:51 PM, mark sheppard <macanaoire at hotmail.com> wrote:
>
>
> Hi Lance,
> In the ByteArrayChannel is there any merit in making
> the readonly member variable final to exhibit its immutable characteristic
Yes, I would agree and Intellij analyze code also suggests that along with removing final from begin/endRead as the methods are final.
This might be better to do in a separate cleanup
> i.e. it appears to be set during construction only,
> and the closed member variable volatile to ensure consistency of reads
> for concurrent isOpen and closed method invocations ?
It might be better to use begin/endRead calls in the isOpen method.
Best
Lance
>
> regards
> Mark
>
>
>
> From: nio-dev <nio-dev-bounces at openjdk.java.net> on behalf of Lance Andersen <lance.andersen at oracle.com>
> Sent: Thursday 9 April 2020 18:20
> To: Alan Bateman <Alan.Bateman at oracle.com>
> Cc: nio-dev <nio-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE
>
>
>
>> On Apr 9, 2020, at 3:03 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>>
>>> In the case of the close method above, ByteArrayChannel::toByteArray uses a readLock ByteArrayChannel::close uses a writeLock
>>>
>> The patch adds a new lock and doesn't appear use the readLock. Would it be possible to generate a webrev with the full patch as it's not possible to see the fully implications of what is proposed here.
>
> Of course, and can be found at: http://cr.openjdk.java.net/~lancea/8241883/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8241883/webrev.00/index.html>
>
> I modified the patch to use the beginWrite() from ByteArrayChannel per Christoph’s suggestion (I had done that originally but talked myself out of that for some reason …)
>>
>> -Alan
>
> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200409/50bc94b9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200409/50bc94b9/oracle_sig_logo-0001.gif>
More information about the nio-dev
mailing list