commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Lucas (JIRA)" <>
Subject [jira] [Commented] (IMAGING-128) TIFF Image Writer is not flushing output
Date Thu, 19 Jun 2014 14:50:24 GMT


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:
>             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
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

View raw message