commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [IO] Progress Monitor
Date Thu, 08 Apr 2010 23:51:16 GMT
> -----Original Message-----
> From: Rafał Krupiński []
> Sent: Thursday, April 08, 2010 04:03
> To: Commons Developers List
> Subject: Re: [IO] Progress Monitor
> On Wed, Apr 7, 2010 at 12:09 AM, Gary Gregory
> <> wrote:
> [..]
> > When I am copying a directory containing possibly hundreds of files, I do
> want to know how far along I am. Recall that File
> >objects describe both files and directories.
> Good point.
> > The progress monitor itself can decide if the operation is fast enough to
> not bother with providing actual progress feedback. For example, Eclipse does
> not bring up the progress dialog if an operation is fast enough. This is a
> subtlety left to progress monitor implementations though.
> Yes, but in Eclipse the decision is based on a timer and it doesn't
> need support from a ProgressMonitor interface or the monitored
> service.
> What level of details would copy(File,File) provide when copying a
> deep directory structure? What performance penalty would it cause.
> What about users who don't need progress monitoring?

You use the current API. For example, a made-up example:

FileUtils.copy(File, File) stays as is. A new method is created:
FileUtils.copy(File, File, ProgressMonitor)

You only use the API you need.

We cannot remove the (File,File) API of course. We could deprecate it but that does not seem
right for this compoenent.

Internally, it makes sense for the (File,File) method to call (File,File,ProgressMonitor)
API with null or a NullProgressMonitor (which does nothing). It seems easier to pass in a
NullProgressMonitor instead of checking for null all over the place.


> --
> Pozdrawiam / Best Regards
> Rafal Krupinski
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message