You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Kevin Jackson <ke...@it.fts-vn.com> on 2004/11/10 07:01:20 UTC

[Patch] change org.apache.tools.ant.taskdefs.Concat to use static method FileUtils.readFully

Was calling the method in a non-static manner.  Single letter change 
from fileUtils -> FileUtils.

Most of the newer code in FileUtils is non-static, but most of the older 
code is static, is this a historical oddity, or is there a reason for it?

Also the contructor is protected, but there's no need as the 
getFileUtils always returns a new object.  Why, wouldn't it be simpler 
to leave the constuctor as normal and use the class as a normal class, 
or to change the class to be a true Singleton, or to make it a 
completely static class?

Just some thoughts, there's probably a very good reason why it's the way 
it is, but I haven't figured it out yet.

Kev



Re: [Patch] change org.apache.tools.ant.taskdefs.Concat to use static method FileUtils.readFully

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 01 Dec 2004, Jesse Glick <je...@sun.com> wrote:
> Stefan Bodewig wrote:
>> Initially we thought we'd provide subclasses for different OSes
>> like OpenVMSFileUtils or NetwareFileUtils and would use
>> newFileUtils as a factory method.

> But it seems that various methods already do OS-dependent checks;
> this should work equally well with static methods, right?

Yes.  You must have missed my

> We never did so, though.

The way the methods are implemented is not the way we envisioned when
we made FileUtils a factory.  Somehow the OS dependent code crept into
the methods as ifs instead of getting rolled into subclasses.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: [Patch] change org.apache.tools.ant.taskdefs.Concat to use static method FileUtils.readFully

Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
> Initially we thought we'd provide subclasses for different OSes like 
> OpenVMSFileUtils or NetwareFileUtils and would use newFileUtils as a 
> factory method.  We never did so, though.
> 
> Some of the functionality would be the same among all OSes (like 
> closing streams or reading files completely) and could be static, 
> others like normalizing file names would be OS dependent and had to
> be non-static.

But it seems that various methods already do OS-dependent checks; this 
should work equally well with static methods, right? Since the OS does 
not change during the VM lifetime (I would hope!) there is no reason to 
keep any state in a FileUtils instance (you could use static variables 
if you needed to cache something), so there is no reason to have an 
instance at all.

-J.

-- 
Jesse Glick <ma...@sun.com> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: [Patch] change org.apache.tools.ant.taskdefs.Concat to use static method FileUtils.readFully

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 10 Nov 2004, Kevin Jackson <ke...@it.fts-vn.com>
wrote:

> Most of the newer code in FileUtils is non-static, but most of the
> older code is static, is this a historical oddity, or is there a
> reason for it?

I don't think it is an older/newer thing.

Initially we thought we'd provide subclasses for different OSes like
OpenVMSFileUtils or NetwareFileUtils and would use newFileUtils as a
factory method.  We never did so, though.

Some of the functionality would be the same among all OSes (like
closing streams or reading files completely) and could be static,
others like normalizing file names would be OS dependent and had to be
non-static.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org