Bug 26904 - Deprecate evil Java-specific methods in Filesystems API
Deprecate evil Java-specific methods in Filesystems API
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
3.x
All All
: P3 (vote)
: 3.x
Assigned To: Jesse Glick
issues@platform
http://www.netbeans.org/download/dev/...
: API
Depends on:
Blocks: 26921 27643
  Show dependency treegraph
 
Reported: 2002-08-30 01:52 UTC by Jesse Glick
Modified: 2008-12-22 17:39 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
:


Attachments
Proposed patch (15.39 KB, patch)
2002-08-30 02:37 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-08-30 01:52:16 UTC
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('/', '.').
Comment 1 Jesse Glick 2002-08-30 02:37:26 UTC
Created attachment 7256 [details]
Proposed patch
Comment 2 Jesse Glick 2002-08-30 02:43:48 UTC
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
Comment 3 Jaroslav Tulach 2002-08-30 08:02:08 UTC
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.
Comment 4 Jaroslav Tulach 2002-08-30 08:03:02 UTC
I was also thinking about adding FileObject.getResourceName () as a
replacement for getPackageName, but that is not as necessary as the
findResource.
Comment 5 Jaroslav Tulach 2002-08-30 08:05:45 UTC
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.

Comment 6 Svata Dedic 2002-08-30 08:07:51 UTC
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).
Comment 7 Jesse Glick 2002-08-31 15:37:20 UTC
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.
Comment 8 Jesse Glick 2002-08-31 17:19:09 UTC
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
Comment 9 David Strupl 2002-09-27 14:32:24 UTC
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.
Comment 10 Peter Zavadsky 2002-09-30 16:06:13 UTC
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.
Comment 11 Jesse Glick 2004-03-16 16:58:52 UTC
Fixed a few more in promo-D.


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