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.

Bug 26904

Summary: Deprecate evil Java-specific methods in Filesystems API
Product: platform Reporter: Jesse Glick <jglick>
Component: FilesystemsAssignee: Jesse Glick <jglick>
Severity: blocker CC: jtulach, rmatous, sdedic
Priority: P3 Keywords: API
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: TASK Exception Reporter:
Bug Depends on:    
Bug Blocks: 26921, 27643    
Attachments: Proposed patch

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       
committed   * Up-To-Date  1.54       
committed   * Up-To-Date  1.64       
committed   * Up-To-Date  1.15       
committed   * Up-To-Date  1.41       
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
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
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
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,


is more obvious than


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/
committed   * Up-To-Date  1.92       
committed   * Up-To-Date  1.5         openide/compat/test/build.xml
committed   * Up-To-Date  1.4        
committed   * Up-To-Date  1.20       
committed   * Up-To-Date  1.76       
committed   * Up-To-Date  1.58       
committed   * Up-To-Date  1.61       
committed   * Up-To-Date  1.55       
committed   * Up-To-Date  1.65       
committed   * Up-To-Date  1.12       
committed   * Up-To-Date  1.70       
committed   * Up-To-Date  1.56       
committed   * Up-To-Date  1.101      
committed   * Up-To-Date  1.37       
committed   * Up-To-Date  1.9        
committed   * Up-To-Date  1.64       
Comment 9 David Strupl 2002-09-27 14:32:24 UTC
Sorry but what is the connection between this and classpath related

    /** 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
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.