[
https://issues.apache.org/jira/browse/IMAGING-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037387#comment-14037387
]
Gary Lucas commented on IMAGING-128:
------------------------------------
Well, I am not deeply committed to this one-line change. I mainly intended it
as a way of offering a bit of forgiveness for a programmer who makes a mistake
using the TiffImageWriterBase class (which is normally buried deep inside the
Image API and not accessed unless one has a special interest in TIFF files.).
That being said, Gary Gregory is absolutely right about one thing... There is a
reason that any non-trivial application implements a buffer on file I/O and we
shouldn't thwart that purpose by introducing flushes to the code at any except
at the conclusion of major operations. Whether we accept this patch or not,
there is no good reason to start introducing flushes to the code base without
careful thought.
So if we don't think this change is a good idea as a matter of aesthetics,
general "best practice", or efficiency considerations... what we should do is
reject this tracker issue and clear it out of the open-items list. And while I
wish had this discussion before I took the trouble of creating the patch, I
don't view it as a big deal. Let's just get this issue cleared up one way or
another so we can move on to the next thing.
> TIFF Image Writer is not flushing output
> ----------------------------------------
>
> Key: IMAGING-128
> URL: https://issues.apache.org/jira/browse/IMAGING-128
> Project: Commons Imaging
> Issue Type: Bug
> Reporter: Gary Lucas
> Priority: Minor
> Attachments: Imaging_128_Patch_1.patch
>
>
> The writeImage() method in the TiffImageWriterBase class takes an
> java.io.OutputStream argument as the destination for its output. It does not
> explicitly call flush() on the output stream when it is finished writing
> data. If the calling application allows the output stream to go out of
> scope, rather than explicitly calling close(), any pending output will be
> lost and the output image file will be left in a broken state. Although,
> ideally, applications SHOULD explicitly call close() on an i/o file, we
> should probably add a call to flush to the writeImage method to provide some
> robustness.
> This behavior was observed in Java 7.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
