On 29.12.2003 07:26:47 Henri Yandell wrote: > > IO's been sitting there for a bit. We've had some minor usage, but not a > lot yet. I think we need to get things out the door asap. > > The task file says that: > > 1) IOUtils: Remove toByteArray variants with bufferSize. Jeremias has > reasons for this at: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html > > I'm happy for it to be removed if Jeremias feels it should. > > 2) FileUtils needs cleaning up. > > 3) Test cases needed for: > > EndianUtils 'InputStream/OutputStream' methods. > LockableFileWriter > ClassLoaderObjectInputStream > SwappedDataInputStream > ProxyXxx's [pretty easy to test, and not that much to test as easy to > inspect by eye] > > > > And that's all we really have on the list. > > > 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. BTW, IOUtils still has some deprecated methods that we can now remove. > 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. > 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. > 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? > 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. > On 3), these are bitches to write tests for, except for the Proxy classes > which are easy enough. Personally, I'm happy for us to release without > tests for these, either because: > > a) We release at 0.9 or something, or 1.0-beta, or > b) we don't release with these classes +1 Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
