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.
Should be self-explanatory. The only problem is FileObject.toString(). I suggest to enforce in the documentation that this must give the path from filesystem root (with no implication that this path is useful for Java classpaths). This is incompatible since some old FileObject subclass might have overridden it: public String toString() { return "MyFileObject[" + getNameExt() + "]"; } and now have to delete that override or replace with getPackageName('/', '.').
Created attachment 7256 [details] Proposed patch
Committed. FileObject.toString change can be rolled back/modified if you can think of a better way to do it. committed * Up-To-Date 1.91 openide/api/doc/changes/apichanges.xml committed * Up-To-Date 1.54 openide/src/org/openide/filesystems/FileObject.java committed * Up-To-Date 1.64 openide/src/org/openide/filesystems/FileSystem.java committed * Up-To-Date 1.15 openide/src/org/openide/filesystems/FileSystemCapability.java committed * Up-To-Date 1.41 openide/src/org/openide/filesystems/Repository.java
I checked the diff and I am surprised by the deprecation of findResource. It is definitively ok to deprecate find (....), but findResource not connected to java and should not be deprecated. Btw. there is nearly no other way how to use the FS API, findResource is the most generic access point. I propose to undeprecate Repository.findResource and FileSystem.findResource.
I was also thinking about adding FileObject.getResourceName () as a replacement for getPackageName, but that is not as necessary as the findResource.
Btw. there might be a way how to ensure that nobody overrides toString. You can make it final and use bytecode patching to revert it to non-final.
Hmm... I think that the semantic connection between FileSystem roots is quite vague - at least in Repository.getDefault(): what's the relation of /home/user, /home and /tmp/cvs/fooproject ? And if there is none, what's the meaning of relative path (which findResource is for) from such bunch of unrelated things ? But FileSystem.findResource is other story as it is often needed. There's a RFE to allow getFileObject to accept relative paths (or provide other similar method which will accept it) - if that is done, findResource will become only a convenience, since it will equal to fs.getRoot().getFileObject(relativepath).
I agree, I will make toString source-final. I will also introduce a new method getPath which does the same thing - inverse of FileSystem.findResource - but which is guaranteed to work correctly. (Otherwise calling toString() on a FileObject from an old compiled module could yield incorrect results.) Anyway, fo.getPath() is more obvious than fo.toString() for someone not very familiar with the APIs. It may be convenient to overload toString() for other purposes, but it reduces code clarity IMHO. Same reason people complain about operator overloading in C++. Re. deprecating Repository.findResource methods - I will defend this. They continue to work as before, and their semantics is well-defined; but it is hard to imagine what use you could have for these methods unless you were making incorrect assumptions about Repo <-> classpath. Deprecating them will help module authors find such bad code more quickly. Deprecating toString() should also help serve as a reminder to people to examine their code - either the call to toString() should be changed to getPath(), or to something using ClassPath. I have found this helpful already in apisupport - I am just looking for deprecation warnings and have found a number of places where I assume Repo = classpath that I had completely forgotten about.
committed * Up-To-Date 1.112 openide/build.xml committed * Up-To-Date 1.70 openide/openide-spec-vers.properties committed * Up-To-Date 1.92 openide/api/doc/changes/apichanges.xml committed * Up-To-Date 1.5 openide/compat/test/build.xml committed * Up-To-Date 1.4 openide/compat/test/unit/src/org/openide/CompatibilityTest.java committed * Up-To-Date 1.20 openide/src/org/openide/execution/NbClassPath.java committed * Up-To-Date 1.76 openide/src/org/openide/filesystems/AbstractFileObject.java committed * Up-To-Date 1.58 openide/src/org/openide/filesystems/AbstractFolder.java committed * Up-To-Date 1.61 openide/src/org/openide/filesystems/DefaultAttributes.java committed * Up-To-Date 1.55 openide/src/org/openide/filesystems/FileObject.java committed * Up-To-Date 1.65 openide/src/org/openide/filesystems/FileSystem.java committed * Up-To-Date 1.12 openide/src/org/openide/filesystems/FileURL.java committed * Up-To-Date 1.70 openide/src/org/openide/filesystems/JarFileSystem.java committed * Up-To-Date 1.56 openide/src/org/openide/filesystems/LocalFileSystem.java committed * Up-To-Date 1.101 openide/src/org/openide/filesystems/MultiFileObject.java committed * Up-To-Date 1.37 openide/src/org/openide/filesystems/MultiFileSystem.java committed * Up-To-Date 1.9 openide/src/org/openide/filesystems/URLMapper.java committed * Up-To-Date 1.64 openide/src/org/openide/filesystems/XMLFileSystem.java
Sorry but what is the connection between this and classpath related issue? /** Searches for the given resource among all filesystems. * @see FileSystem#findResource * @param name a name of the resource * @return file object or <code>null</code> if the resource can not be found * @deprecated Please use the <a href="http://www.netbeans.org/download/dev/javadoc/JavaSupportAPIs/org/netbeans/api/java/classpath/api.html">ClassPath API</a> instead. */ public final FileObject findResource(String name) { Shouldn't this be undeprecated? It is similar to toString() issue - bad usage does not mean we should leave it deprecated. I am creating an issue to check all usages in core/openide - 27643.
From David's comment I created new task (issue #27687). Beside that and the issue #27640 (undeprecating FO's toString), I guess this issue is fixed already.
Fixed a few more in promo-D.