Jakarta Commons Team is happy to announce version 1.0 of the Jakarta Commons-IO library. Jakarta Commons-IO contains utility classes, stream implementations, file filters , and endian classes.
View the Jakarta Commons-IO home pageDownload Commons-IO
Looks useful but... I hope your code is more robust than your doc.
Found this after two minutes of browsing:
The link to the IOUtil class in the main package doc is broken (the class has been renamed "IOUtils").
Most of the doc in IOUtils refers to the copy(...) methods. These are not in IOUtils but in CopyUtils.
Link to UnixReview article goes to empty page.
Doc of HexDump.dump(...) offset parameter:
"offset - its offset, whatever that might mean"
Should I ask how many other commons packages it relies on? I think I'll wait for Hani's review before I look at it. ;)
They've butchered IOUtils from Avalon. It used to be a set of copy(String|byte|Reader|Stream, String|byte|Reader|Stream) methods. There are a lot of permutations, and that was the point of the class -- do it once, get them all in one place. Someone didn't understand that, and split the copy(*, [String|byte) methods into "CopyUtils", not even bothering to update the javadocs.
Hopefully I still have commit karma and can remove my @author tag.
On the project's page we can read :
IO has recently been promoted from the commons sandbox, however there remains no formal release at present.
I don't know why the lack of documentation is considered to be cool with many open source projects ?
Isn't that standard for Jakarta projects, poor code and worse documentation? Why does Sun trust Jakarta with RI's when they consistently churn out the worse code of all the FOSS groups (like codehaus, open symphony etc.)?
Can you help us to write the documentation?
Personally I find it sad that the first thing people choose to do is criticise. Constructive criticism is valid and welcomed - bitching is not.
For the record:
1) The IO javadoc is all correct and up to date - unfortunately the release manager hasn't updated the website. Download the code and its correct.
2) IO does not depend on any other commons library (and changes are happening to other commons libraries on the dependency front too)
3) The code is taken from various sources, including Avalon. Thats part of the point of jakarta-commons - to refactor out common code. Once in commons, the best design for a component is then chosen, and experience has indicated that creating very large utils classes is not helpful. Hence CopyUtils was broken out from IOUtils.
I, for one, am very pleased to see the release of this library.
Committer Jakarta Commons
This is quite a bemusing piece of news, especially in the wording.
Jakarta Commons IO has not been released. The binaries are, as of the weekend, on the mirrors and maven repository, but the website hasn't been updated and no announcements have been made, on the site or by email.
On the one hand, I know I [as person releasing it] am not up to the standards of other releases. My goal is to get it released, even if the process is a week. On the other hand, this obviously shows that people watch the mirrors like a hawk and are happy to treat a binary appearing on a mirror as a full release. So this is my fault for underestimating the interest and attentiveness of the community.
There is one thing I would like to know however, which is where Dion got the announcement that he posted from. I've seen no such announcement going out, and in no way have written such an announcement itself. Is it a forgery?
[Due to this jumping of the gun, I've gone ahead and made the time for a release a little earlier than planned.]
The Jakarta Commons team is pleased to announce the release of
Commons-IO contains utility classes, stream implementations, file filters,
and endian classes.
For more information on Jakarta Commons/IO, see the Commons/IO web site,http://jakarta.apache.org/commons/io/
So now all the problems can be highlighted for real.
Congratulations to the release of Commons IO (even though your release date was forced due to reasons beyond your control)!
And Henri, always bear in mind that experienced developers are the worst "customer base" you will ever have. There will always be some who think they could have made it better themselves and since it's easier to critize with hindsight than to contribute in advance, go figure...