You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/12/29 07:26:47 UTC
[io] release plans?
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/commons-dev@jakarta.apache.org/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?
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.
toSuffixes(String[]) looks like it's a better fit for 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. What else?
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
Thoughts, opinions, insults?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] release plans?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] release plans?
Posted by Henri Yandell <ba...@generationjava.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Ready for promotion? Was: [io] release plans?
Posted by Henri Yandell <ba...@generationjava.com>.
The core EndianUtils is effectively unit tested now. The Stream wrapper
methods are not yet, and there aren't numerous different types of unit
test etc.
Still, as all the Stream methods sit on top of the Endian ones, I think
the class is generally protected. This leaves:
1) FilenameUtils. Not going in 1.0.
2) Tests for LockableFileWriter, ClassLoaderObjectInputStream,
SwappedDataInputStream. The latter is a small thing that again sits on top
of the EndianUtils Stream classes.
3) A few of the IOUtils tests are testing 1 method from IOUtils and 1 from
CopyUtils. Probably wants the CopyUtils bit removing.
4) Move to Commons proper. [or 0) ]
5) Release.
What do people think about calling a vote for promotion out of the
sandbox now? Apart from deciding which particular classes etc we want to
leave out, there's not a lot more between IO and a first release.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] release plans?
Posted by Henri Yandell <ba...@generationjava.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] release plans?
Posted by Jeremias Maerki <de...@greenmail.ch>.
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/commons-dev@jakarta.apache.org/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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org