commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: [io] Deprecate CopyUtils
Date Mon, 09 Aug 2004 19:08:01 GMT
Sorry for the massive delay. You have some points. Still, I'm reluctant
to merge CopyUtils and IOUtils again because IOUtils will become huge.
Splitting the whole thing into a number of classes will provide
headaches about what to put where and who to name it. It's not always
clear where something should be put. If the thing is mixed up too much
noone will find the method he/she needs. Having said that the one big
IOUtils isn't such a bad idea but has similar problems. But in the end
my gut feeling is that the current setup is not that bad. Read that as a
-0.

Personally, I have no problem with changing APIs but other people are
extremely sensitive about it.

I'm no big help here, I know, but just so you get another opinion.

On 31.07.2004 13:57:10 Stephen Colebourne wrote:
> I have been looking at adding methods to IOUtils/CopyUtils, to handle
> additional types and to fix some holes.
> 
> The net result is a realisation that the CopyUtils class was a poor creation
> (and it may even have been my idea!).
> 
> - CopyUtils implements various methods that write byte[] and String to
> stream/writer but to this inefficiently via other writers/streams.
> - null handling is unclear.
> - the toXxx methods on IOUtils are strongly related to CopyUtils yet they
> are on a different class (they are the read() operations)
> - it is not logical to look on a 'copy' class to find a method when I just
> want to 'write' data (write a string/byte[] to file is not a copy operation
> in most peoples minds.)
> 
> So, I propose the following:
> CopyUtils deprecated, methods moved to IOUtils.
> 
> Write methods (string/byte[] to stream) are renamed to write(...)
> Copy methods (stream to stream) stay named as copy(...)
> 
> The write methods will also change implementation to handle null
> string/byte[] and to be more efficient.
> 
> The main downside is that it annoys users who are using CopyUtils. However,
> it does seem to be better to fix the issue and get the right API.
> 
> 
> Alternatives would include ReaderUtils, WriterUtils, InputStreamUtils,
> OutputStreamUtils, but then where do the actual copy methods go. Plus too
> much breaking up can be troublesome for users too. This strategy of IOUtils
> for low level streams/readers/writers and FileUtils for higher level files
> and FilenameUtils for even higher level seems to work well in my mind.
> 
> If there are no objections I will commit these changes....


Jeremias Maerki


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


Mime
View raw message