Bug 39415

For io.File or URL conversion to FileObject there exist two methods:

    FileObject[] fromFile(File);
    FileObject[] findFileObjects(URL);

There are two issues about them. When overlapping FileSystems are
mounted the methods will return all suitable FileObjects found on all
FileSystems. This is technically correct but has low value for API
clients who in most of the cases simply use the first FileObject and
ignore the rest ones. The FileUtil.fromFile returns results according
to order of filesystems mounted in Repository. However,
URLMapper.findFileObjects returns results in undefined order and so it
is not guaranteed that first FileObject will be the same in subsequent
calls.

I propose to mend this by two new public API methods. These methods
will not depend on the order of filesystems mounted in repository.
They will also return only one FileObject which is the closest match
or null. The existing methods would remain in API for clients who are
interested in all matches.


URLMapper.java:

/**
 * Finds the best FileObject for the given URL. If there is multiple
 * FileObjects available for the URL (use {@link #findFileObjects}
 * method to list them) the FileObject with minimal number of path 
 * components will be choosen.
 *
 * @param url URL for which the FileObject will be searched
 * @return the most suitable FileObject or null if there is not any
 * @since X.XX
 */
public static FileObject findBestFileObject(URL url);


FileUtil.java:

/**
 * Finds the best FileObject for the given File. If there is multiple
 * FileObjects available for the File (use {@link #fromFile} method
 * to list them) the FileObject with minimal number of path components
 * will be choosen.
 *
 * @param file File for which the FileObject will be searched
 * @return the most suitable FileObject or null if there is not any
 * @since X.XX
 */
public static FileObject findBestFileObject(File file);


The target milestone for this change is 3.6. There is no strong
requirement for it but change is safe and useful. It is also in line
with behaviour of planned MasterFS (the filesystem which aggregates
all other filesystems and presents them to user as one).

In attachement you will find working source code patch and unit tests
covering these two new methods.

Created attachment 13161 [details]
source code patch

Note: the patch behaves slightly different from the Javadoc because it
selects the file with the shortest path name (in characters), whereas
the Javadoc specifies the shortest path in number of components
(sections between '/'). It is extremely unlikely that this difference
would matter in practice though, since in all the expected use cases
it will be true that for the paths of any pair of candidate file
objects, one path will be a suffix (after a '/' separator) of the other.

BTW in URLMapperTest,

  String base = workdir.toURI().toURL().toExternalForm();

can be simplified to

  String base = workdir.toURI().toString();

Forgotten issue assigned to devrev?

I think this may be already done, or will be backed out in favor of
something better, etc. Reassigning to Radek to evaluate, perhaps close
as dupe, etc.

*** This issue has been marked as a duplicate of 41506 ***