Re: [io] release plans?
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. Leaving for you to kill. BTW, IOUtils still has some deprecated methods that we can now remove. All seemed to be due to the move of code into CopyUtils. I've removed the deprecated values, pointed IOUtils to CopyUtils for the places it uses copy methods and changed the IOUtilsTestCase to point to CopyUtils. Some of these tests will want to either be deleted or moved to CopyUtilsTestCase if not already there. Other than that, the use of 'final' in method parameters is not normally our communities coding style and we might want to dump that. All finals should be gone from the code now. At least the bad ones. I've left final on classes for the moment, and final on a static variable is a good thing. 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. I've changed the todo to match this. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] release plans?
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]
Re: [io] release plans?
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]
Re: [io] release plans?
Should IOUtils be called StreamUtils? No, as it has readers/writers too. IOUtils is OK, though I would prefer dividing to InputUtils, OutputUtils and CopyUtils. 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. I suggest adding a FileFormatUtils (or some such name) that might also replace HexDump. 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? It has no performance benefit (thats a myth). There was a time when I was adding final in, but now I would probably take it out. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
