commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve cohen <>
Subject Re: [NET] VMSFTPEntryParser bug?
Date Mon, 29 Dec 2003 22:32:25 GMT
On Monday 29 December 2003 04:27 pm, steve cohen wrote:
> I am trying to build commons-net prior to making some changes and some
> other issues have come to light.
> One of the tests is failing for me -
> VMSFTPEntryParserTest.testParseFileList().
> This test seems poorly implemented, since the class being tested builds its
> list of files using a HashMap to eliminate dupes, I presume, and then spits
> out the list by calling values() on the HashMap - which spits out the
> values in an order that is different from the one the test is expecting.  I
> was running this under java 1.3 on linux.  I switched to java 1.4 and it is
> also failing but on a different line.  I'm not sure what platform Jeff is
> on when he did the build, but I think I should rewrite this test in a way
> that doesn't assume any particular order since this seems to be
> JDK-implementation dependent.  The JavaDoc for HashMap specifies no order
> that should be expected for HashMap.values(), nor for HashMap.keySet() for
> that matter.  We could probably achieve a dependable order by using a
> TreeMap.keySet() instead.

However, this brings up a larger question, of what the target platform for 
commons-net is.  I dimly remember that it being java 1.1.  This is why I went 
through the annoying exercise of creating the FTPFileList and FTPFileIterator 
classes based on java-1.1-compatible containers like Vector.  If we are now 
using HashMaps, though, we will have violated this contract, if, in fact, 
such a contract exists.  Can someone clarify this question?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message