Bug 39415 - [devrev] Extend URLMapper and FileUtil with two convenience methods
[devrev] Extend URLMapper and FileUtil with two convenience methods
Status: RESOLVED DUPLICATE of bug 41506
Product: platform
Classification: Unclassified
Component: Filesystems
3.x
All All
: P2 (vote)
: 4.x
Assigned To: rmatous
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-30 12:52 UTC by David Konecny
Modified: 2008-12-22 19:58 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
source code patch (12.00 KB, patch)
2004-01-30 12:56 UTC, David Konecny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2004-01-30 12:52:29 UTC
.
Comment 1 David Konecny 2004-01-30 12:55:26 UTC
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.
Comment 2 David Konecny 2004-01-30 12:56:54 UTC
Created attachment 13161 [details]
source code patch
Comment 3 Jesse Glick 2004-01-30 15:55:00 UTC
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();
Comment 4 Jaroslav Tulach 2004-03-08 08:05:13 UTC
Forgotten issue assigned to devrev?
Comment 5 Jesse Glick 2004-04-02 22:13:05 UTC
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.
Comment 6 rmatous 2004-04-05 08:39:28 UTC

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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo