Tim Ellison wrote:
> I accept your point. Since this comment was quite specific to the issue
> then it seemed fitting to keep that as a JIRA comment, if a jira comment
> opens up a wider consideration then I agree it should be responded to on
> the dev list.
>
To be clear, I certainly agree that it belonged in JIRA. It just got me
thinking about one of my pet peeves that I have no solution for, which
is in itself a pet peeve....
geir
> In this instance, Paulex has a good point about why Vladimir's suggested
> patch will not work. If that comment is not made in the JIRA then there
> is no indication to JIRA readers that the proposed change is in dispute.
>
> Bright ideas always welcome, of course.
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
>> Interesting problem. I do agree with you - keeping it in one place is a
>> good thing, and JIRA is that place.
>>
>> However, I always find it hard to read jira comment streams - they don't
>> feel the same as discussion in regular dev@ mail.
>>
>> I have no idea what to do about this. I've thought about doing
>> discussion here, and then dropping a mail thread ID into the JIRA. That
>> actually would work nicely, maybe. I've also thought about getting JIRA
>> to reformat comments mail to be more like a regular quoted discussion
>> (maybe put that at top, and regular JIRA output at bottom of mail.)
>>
>> Clearly I have no real solution. I figured I'd just complain in case
>> someone else has a bright idea... :)
>>
>> geir
>>
>>
>> Tim Ellison wrote:
>>> Paulex,
>>>
>>> IMHO This would be better as a comment on the JIRA issue itself, then we
>>> can keep them all together. Would you like to repeat yourself there ;-)
>>>
>>> Thanks
>>> Tim
>>>
>>> Paulex Yang wrote:
>>>> The patch does work in some case, but it is not enough.
>>>>
>>>> First, when the channel is closed, the relevant stream(FileInputStream,
>>>> FileOutputStream or RandomAccessFile) also needs to closed. So only add
>>>> codes to the FileOutputStream is not enough.
>>>>
>>>> Second, the FileOutputStream/FileInputStream will close itself in the
>>>> finalize() method(as Java spec says), and with your patch, current
>>>> implementation in Harmony will close the channel at that time, too. This
>>>> is very dangerous, because if someone writes code like below, the fos
>>>> may be garbage collected and closed, and channel will also be closed, so
>>>> that the following operation on channel will throw unexpected exception.
>>>> <code>
>>>> .....
>>>> FileChannel channel = null;
>>>> try{
>>>> FileOutputStream fos = new FileOutputStream("somefile.txt", false);
>>>> channel = fos.getChannel();
>>>> }catch(Exception e){
>>>> }
>>>> /*continue operate on channel*/
>>>> .....
>>>> </code>
>>>>
>>>> Third, the native close operation should only be executed once, so that
>>>> some synchronization mechanism on the channel and stream should be
>>>> introduced, which should also avoid deadlock when one thread is calling
>>>> fos.close() while the other is calling channel.close().
>>>>
>>>> As a conclusion, the close issue is yet another reason that the three
>>>> classes IO package need to be refactored to based on same JNI interface
>>>> with FileChannel. Pls. refer to my work on JIRA issue #42.
>>>>
>>>> Vladimir Strigun (JIRA)
>>>>> [
>>>>> http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705
>>>>>
>>>>> ]
>>>>> Vladimir Strigun commented on HARMONY-40:
>>>>> -----------------------------------------
>>>>>
>>>>> Forced close of file current file channel in file output stream can be
>>>>> added (diff for current FileOutputStream)
>>>>> 173a174,177
>>>>>
>>>>>> if (channel != null) {
>>>>>> channel.close();
>>>>>> channel = null;
>>>>>> }
>>>>>>
>>>>>
>>>>>> FileChannel assotiated with FileOutputStream not closed after closing
>>>>>> output stream
>>>>>> -----------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> Key: HARMONY-40
>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-40
>>>>>> Project: Harmony
>>>>>> Type: Bug
>>>>>> Components: Classlib
>>>>>> Reporter: Vladimir Strigun
>>>>>>
>>>>>
>>>>>> When I receive FileChannel from file output stream, write something
>>>>>> to stream and then close it, channel, assotiated with the stream
is
>>>>>> still open. I'll attach unit test for the issue.
>>>>>>
>>>>>
>
|