RFR: JDK-8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE

[Lance Andersen]

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>