@Elliotte Rusty Harold,
I'd like to make two unrelated points.
1. I wasn't suggesting the missingFilesFirst() or missingFilesLast() methods
as a solution to the issues raised in IO-813 LastModifiedFileComparator
should not throw exceptions, period. I just thought these methods would be
useful for cases where the users needs to sort file collections where some
files might not be valid anymore. This could easily arise in cases that are
unrelated to the issue in IO-813.
2. As for your point about external conditions changing the code, I would like
to point out that working with a file system is hardly the only place where
developers will encounter this problem. In fact, this is a common issue with
multi-threaded code. If you read the javadocs for the java.util.conncurent
package, you will find a definition of "weakly consistent," which applies to
iterators and spliterators of concurrent collections. Among other things, it
says this: "they are guaranteed to traverse elements as they existed upon
construction exactly once, and may (but are not guaranteed to) reflect any
modifications subsequent to construction." This was a change from the behavior
of iterators in the standard collections, which are strongly consistent.
We could deal with the issue of the state of the files changing while a longer
task is in progress by simply adding a note to the Javadocs that this may
happen, and users should design their classes to account for this.
On Dec 1 2023, at 1:07 PM, Elliotte Rusty Harold <elh...@ibiblio.org> wrote:
>
> I'm not sure we need two methods here, or even one. We simply need to
> detect a missing file and assign it a time like Integer.MIN_INT. Make
> the behavior as reproducible as reasonable for the case where the file
> doesn't exist and never existed.
>
> For cases where the last modified time changes or a file is deleted
> while a sort is executing, well that's why probably this class should
> be deprecated. No sorting algorithm is stable or correct when sorting
> by external conditions that change asynchronously outside the
> program's control while the sort executes.
>
>
> On Fri, Dec 1, 2023 at 4:50 AM Miguel Muñoz <swingguy1...@gmail.com> wrote:
> >
> >
> >
> > In my comments about issue IO-813 LastModifiedFileComparator should
> not throw exceptions, period, I made a suggestion that I thought I'd repeat
> here. I was thinking of adding these two methods to AbstractFileComparator.
> >
> >
> >
> > public static Comparator<File>
> missingFilesFirst(Comparator<File> comparator)
> >
> >
> > public static Comparator<File>
> missingFilesLast(Comparator<File> comparator)
> >
> >
> > These would work like Comparator.nullsFirst() and
> Comparator.nullsLast(). They would allow users to work with collections of
> Files that might not point to valid files, without having to worry about
> IOExceptions.
> >
> >
> >
> > I'm not sure if AbstractFileComparator is the best place to put it. It's
> not a public class, but the methods would be available from any of the
> subclasses. A better place might be in FileUtils, although that's in a
> different package.
> >
> >
> >
> > What do you think?
> >
> >
> >
> > -- Miguel Muñoz
> >
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
