Well, copy done ;-)
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.
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.
--
Paulex Yang
China Software Development Lab
IBM
