On Mon, 29 Dec 2003, Jeremias Maerki wrote:
> > On 29.12.2003 07:26:47 Henri Yandell wrote: > > > > On 1), it seems that Jeremias is driving this one. What's the status > > Jeremias? > > I was just waiting for someone to comment on that, but I guess noone > objects so we can just delete these methods. I can do that tomorrow if > nobody does it first. Go for it. The benchmark seems to show that it doesn't make a difference now. > BTW, IOUtils still has some deprecated methods that we can now remove. Kill em. Though looking at them does cause me to think a bit as I hadn't noticed CopyUtils. Should IOUtils be called StreamUtils? Why are File copy things not in CopyUtils? > > On 2), we need to define what this actually means. I suspect by and large > > it means moving things about between FileUtils, FilenameUtils and IOUtils. > > For example: > > > > byteCountToDisplaySize is not File based but a simple helper to show a > > number in 1024 units, much like -h flag to 'du' or 'df'. Still, not sure > > it fits anywhere else either and it is handy-ish. > > It's nice-to-have. Should we move to to a separate class? I'm not sad if > we remove it, though. Could go to IOUtils, but otherwise I think it's fine in FileUtils unless someone obejcts. > > toSuffixes(String[]) looks like it's a better fit for FilenameUtils. > > Well, this method should have been private, a helper method to listFiles. > I can't explain right now why this ended up public. I'd make it private > again unless someone wants it public and then it would have to move to > FilenameUtils. Made private. > > Other than that, the use of 'final' in method parameters is not normally > > our communities coding style and we might want to dump that. > > Doesn't the 'final' modifier help the JIT to improve speed? Only in inheritence I think. There's no inheritence in: public static boolean contentEquals(final File file1, final File file2) it's only usefulness is to stop someone reusing the file1 and file2 variables, which some people consider to be a bad practice. > > What else? > > FileUtils is already pretty clean. But now that we've split off > FilenameUtils, that's where the whole mess is right now. Some of these > methods only work on unix systems. I've started rewriting code for that > class but have stopped again as this need some discussion. I can > probably write that up tomorrow. FilenameUtils has some deactivated > test cases that if activated fail. There some major work left there. Cool. A write up would be good as to what the problems are etc. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
