This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
.
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 ***